items tagged with classpath

• System classloader is the content of the system variable CLASSPATH= you defined higher level
• Loader of the servlet runner is own classloader of Resin, tomcat or other
• Application classloader (controlled by resin or tomcat) find classes which are in the webapps directory (Application class).
• Your own classloader if you write own lower level

As soon as you request a class in one of these loader, the classloader will take the first found during its walk under this rules:

• if the class is not found at the current level (place where you request it, most of the time in your application), it will try to load it from the upper level, if not found it will continue and finish in the system classloader.
• There is no downward request.

 java.lang.ClassNotFound and ClassNotDefFoundError are different but what if my classes are in classpath?

 Remember:

• ClassNotDefFoundError is thrown if a class definition of the hierarchy is not located by the classloader
• ClassNotFound if the file or class can not be found in classpath. Remember only some servletrunner can open jar files, so having jar files in a directory without having them explicitely in classpath do not help much. You must have the name of jar file in CPath.

What can you do to avoid that when you use one Maven dependency, to also inherit some other undesirable older
dependency (which is to say from an older transitive dependency).

The fix to this is to add an exclusion to the dependency in question.
For example, if we start with a dependency upon version 1.2 of the jxpath library:

<dependency>
   <groupId>common-jxpath</groupId>
   <artifactId>common-jxpath</artifactId>
   <version>1.2</version>
   <scope>compile</scope> <!-- default scope for sake of example-->
</dependency>

This dependency to jxpath 1.2 will bring in an old version of log4j 3.8. In order to ensure that I am using the latest
versions of log4j (4.4),

I need to put in an exclusion for these transitive dependencies of common-jxpath, which I do as follows:

<dependency>
   <groupId>common-jxpath</groupId>
   <artifactId>common-jxpath</artifactId>
   <version>1.2</version>
   <scope>compile</scope> 
   <exclusions>
      <exclusion>
         <artifactId>junit</artifactId>
         <groupId>junit</groupId>
      </exclusion>
      <!-- I can put many of these here -->
   </exclusions>
</dependency>

Having excluded them, they will be any longer in the build.

In a multi modules project where you have write API or common code for unit tests in one project and want to reuse these in the tests for another project. Maven will crash during the compile phase if you do not make the following.

Maven rules of the game:

• The main code in src/main/java is visible across modules if you did specify project
  dependencies in pom.xml.
• Test code reside in src/test/java and is not shared across modules, moreover
• Test code can use any code from src/main/java but not the other way around, which
  make sense as we want to clearly separate test code (junit testcases) from code shipped.

The solution is to create additional test jar for each module, this is done by putting in the
parent pom (lets call it parent-pom.xml)

inside the <build></build> tags the following:

   1:  <plugin>

   2:    <groupId>org.apache.maven.plugins</groupId>

   3:    <artifactId>maven-jar-plugin</artifactId>

   4:    <executions>

   5:      <execution>

   6:        <goals>

   7:          <goal>test-jar</goal>

   8:        </goals>

   9:      </execution>

  10:    </executions>

  11:  </plugin>

This will create for each modules an additional jar named {artifactId}-{version}-tests.jar
during the goal test-jar

Now for every modules where you want to reuse test classes, all you have to do in to put in every
modules pom.xml a dependency to that test jar by adding the tests classifier

   1:  <dependency>

   2:        <groupId>yourGroup</groupId>

   3:        <artifactId>yourReusableModuleArtifact</artifactId>

   4:        <version>0.1-SNAPSHOT</version>

   5:        <classifier>tests</classifier>

   6:        <scope>test</scope>

   7:  </dependency>

This has work for me with Maven 2.0.8

 Java problem N°1

On windows NT machine, command line length is limited to 1024 characters!, clearly not enough for a distributed classpath with a lot of frameworks or 3rd party tools.

Solutions

• Reduce number of jar files, instead of having 10 jar files, you can try to build only one, use automatic build process, with jakarta ANT during the build and for your deployment. This is often not a good/verybad solution.
• Put the half classpath size in java ext classpath (if you use resin or tomcat)

• Use cygwin to start the java process, for example you can use a bash terminal. But do not use cygrunsrv as it was not designed for installing java process as NT service: it wil create a ghost program when you kill the service.
• Last chance, put the classpath in a .txt file and create a classloader which will read it and set the classpath (adaptative classloader). You must create your own classloader!