A customer is certifying their product with CTS (J2EE compatibility test suite) on 1.4.2_08. All CTS tests run fine on 1.4.2_04, but some of the tests are failing with 1.4.2_08. Below is the customer's description of the failure they are seeing:

-------------- when run on 1.4.2_08----------------
java.lang.NoClassDefFoundError: Illegal name: com/sun/cts/tests/ejb/ee/tx/txbean/TxBean

      at java.lang.ClassLoader.defineClass(ClassLoader.java:538)

      at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)

      at com.sun.enterprise.util.EJBClassLoader.findClass(EJBClassLoader.java:254)

      at java.lang.ClassLoader.loadClass(ClassLoader.java:289)

      at java.lang.ClassLoader.loadClass(ClassLoader.java:235)

      at com.sun.enterprise.util.JarClassLoader.loadClass(JarClassLoader.java:59)

      at com.sun.ejb.codegen.GeneratorDriver.preDeploy(GeneratorDriver.java:720)

      at com.sun.enterprise.tools.deployment.backend.JarInstallerImpl.deployEjbs(JarInstallerImpl.java:707)

      at com.sun.enterprise.tools.deployment.backend.JarInstallerImpl.deployApplication(JarInstallerImpl.java:221)

      at org.omg.stub.com.sun.enterprise.tools.deployment.backend._JarInstallerImpl_Tie._invoke(Unknown Source)

      at com.sun.corba.ee.internal.corba.ServerDelegate.dispatch(ServerDelegate.java:355)

      at com.sun.corba.ee.internal.iiop.ORB.process(ORB.java:255)

      at com.sun.corba.ee.internal.iiop.RequestProcessor.process(RequestProcessor.java:84)

      at com.sun.corba.ee.internal.orbutil.ThreadPool$PooledThread.run(ThreadPool.java:99)

 

This problem is coming in the Sun's J2EE RI server as part of deploying the client app there. The relevant code in preDeploy method of com.sun.ejb.codegen.GeneratorDriver is
  Set extraStubClasses = new HashSet();
  for(Iterator entriesIterator = context.getArchive().iterator(); entriesIterator.hasNext();)

        {

            String nextClassName = null;

            String entry = (String)entriesIterator.next();

            if(entry.endsWith(".class"))

            {

                nextClassName = context.getClassName(entry);

                try

                {

                    Class nextClass = jcl.loadClass(nextClassName);

                    if(((javax.ejb.EJBHome.class).isAssignableFrom(nextClass) || (javax.ejb.EJBObject.class).isAssignableFrom(nextClass)) && (!ejbHomeInterfaces.contains(nextClassName) && !ejbRemoteInterfaces.contains(nextClassName)))

                    {

                        extraStubClasses.add(nextClassName.replace('/', '.'));

                    }

                }

                catch(Throwable t) { }

            }

        }

So before loading the class, the className is fetched from context.getClassName(entry)
The code for the same is:

public String getClassName(String fileName)

    {

        String className = fileName;

        if(className.startsWith(getTempDirectory().toString()))

        {

            className = className.substring(getTempDirectory().toString().length());

        }

        if(className.indexOf(".java") != -1)

        {

            className = className.substring(0, className.indexOf(".java"));

        } else

        if(className.indexOf(".class") != -1)

        {

            className = className.substring(0, className.indexOf(".class"));

        }

        className = className.replace(File.separatorChar, '.');

        if(className.charAt(0) == '.')

        {

            className = className.substring(1);

        }
        return className;
    }

This seems to be goofing up in replacing File.separatorChar with ‘.’ as the className fetched from the jar entry has ‘/’ as separator but on Windows box, File.separatorChar is ‘\’. Hence the issue. It passes on 142_04 as the defineClass method of ClassLoader doesn’t seem to throw exception when classname has ‘/’ but throws the same in 142_08.

We tried to catch this exception and load the class again with proper name. This allows to pass the tests which were failing earlier.