Help! Strange class path issue

[blakexiao]

Hi,

I have a lot experience with Java on other platforms but am totally new to iSeries/AS400. I ran into a strange problem recently and hope someone can enlighten me.

We have an Java application packaged as a jar file and depends on a number of libraries. The application uses a custom LOG4J appender which uses JavaMail API to send errors out as email. The application has been in production for 2 years, but 3 weeks suddenly stopped working in one of the test environments.

The symptom is a NoClassDefFoundError when trying to load the javax.mail.internet.InternetAddress class. This class is in the mail.jar.

I verified the manifest.mf of the application jar file and confirmed that the classpath was right (it hasn't changed for a while). To make sure the jar files are not corrupted, I even copied the jar files and libraries to my windows box. It loads the classes perfectly fine on windows box.

I also tried to check if the permissions had changed on the files using QSH (not sure that's the right way, I only know unix, not AS400). The permission string for the mail.jar is "-rwxr-xr-x" which seems to be right. I even tried to use jar -xf to extract the jar files and it worked fine too. So I'm reasonably sure that the mail.jar file is not corrupted.

I have asked our AS400 admin and he doesn't have a clue either...

java.lang.NoClassDefFoundError: javax/mail/internet/InternetAddress
at java.lang.Throwable.<init>(Throwable.java:195)
at java.lang.LinkageError.<init>(LinkageError.java:36 )
at java.lang.NoClassDefFoundError.<init>(NoClassDefFo undError.java:40
)
at java.lang.Class.privateGetDeclaredMethods(Class.ja va:1691)

[BenThurley]

Re: Help! Strange class path issue

I've experienced similar classpath pain on the AS400. The Exception is either NoClassDefFound or NoSuchMethod. It took a lot of messing about to find that there were two versions of the same jar in different folders on the IFS. The error is because the JVM is picking up the older version which doesn't have the class or method in question.

The upsetting thing is that none of this should matter. Theoretically the JVM will only load the version that you set on the classpath. However, replacing the older jar with my new version did fix the problem, even though that folder wasn't on the classpath!

I believe there is a default folder into which you can place jars that you always want on the classpath. This exists on any platform with Java installed. I call this the "system classpath". Originally I used this to explain my problem. I was told that when someone had wanted to use this jar previously that it had already been in the "system classpath" folder.

This explanation held true for sometime until we wanted to use another jar and discovered the same problem. This time the older jar was hanging around in an entirely different IFS folder but again replacing it with a newer version fixed the problem.

I've only ever experienced this problem on the AS400 so either it's setup incorrectly or it's just a rubbish platform. I've struggled to find anyone that knows much about it because most AS400 bods are either dead against Java or have only dabbled.

Hope that helps some.

[MichaelCatalani]

Re: Help! Strange class path issue

I am far from a java expert, but I had to debug something like this some time ago. It was similar to what Ben described. An existing jar file name was duplicated, but without one of the definitions the existing file had.

Here's a snippet from the IBM manual that describes the classpath searches that are performed.

J2SDK searches for classes differently than JDK 1.1.x. JDK 1.1.x searches the system classpath first, then any user-specified classpaths. J2SDK searches the bootstrap classpath first, then the extension directories, then the classpath.


So, the search order for JDK 1.1.x, using the example code above, is:

1. The default system classpath,
2. The current working directory,
3. The myclasses.zip file that is located in the "root" (/) file system,
4. The classes directory in the Product directory in the "root" (/) file system.

The search order for J2SDK, using the example code above, is:

1. The bootstrap classpath, which is in the sun.boot.class.path property,
2. The extension directories, which is in the java.ext.dirs property,
3. The default system classpath,
4. The current working directory,
5. The myclasses.zip file that is located in the "root" (/) file system,
6. The classes directory in the Product directory in the "root" (/) file system.

[BenThurley]

Re: Help! Strange class path issue

I wanted to see what was in this java.ext.dirs property so I looked up a program on the Internet and then adapted it to run in the console.

package cts;

// File: io/properties/SysPropList.java
// Description: Shows system properties in the console.
// Author: Fred Swartz / Ben thurley
// Date:   19/03/2009

import java.util.*;

/** Generic main program. */
public class SysPropList {
    public static void main(String[] args) 
    {
        Properties pr = System.getProperties();
        Set propKeys = new TreeSet(pr.keySet());  // TreeSet sorts keys
        for (Iterator it = propKeys.iterator(); it.hasNext(); ) 
        {
            String key = (String)it.next();
            System.out.println(key + "=" + pr.get(key));
    }
}

} 

Compile that into a jar with the following manifest file.

Manifest-Version: 1.0
Main-Class: cts.SysPropList 

Then drop the jar in a folder on the IFS. change your current directory to whichever one you placed the jar with CD 'ifsfolder' and then run it with JAVA 'jarname.jar'.

On our machine the java.ext.dirs folder was the one we had initially had the problem with. The system classpath was chock a block with IFS locations. The strange thing about all of this is that nobody here would know how to fiddle with this and it was the same on our customers machines. It must, therefore, be like this out of the box.