Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6316808

REGRESSION: behavior change of ClassLoader.checkName() in 1.4.2_05 causes CTS test failure

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Duplicate
    • Affects Version/s: 1.4.2_08
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_xp

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              mmma Marvin Ma (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: