MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-1062

ClassLoader exception when af:forEach is used with CLIENT_STATE_METHOD "all"

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.7-core
    • Fix Version/s: 1.0.8-core, 1.2.8-core
    • Component/s: None
    • Labels:
      None

      Description

      To reproduce, set CLIENT_STATE_METHOD to "all", and run a page with af:forEach that performs postback.

      The following exception will be thrown:

      2008-04-21 15:29:37.117
      oracle.classloader.util.AnnotatedClassNotFoundException:

      Missing class: javax.servlet.jsp.jstl.core.IndexedValueExpression

      Dependent class: java.io.ObjectInputStream
      Loader: jre.bootstrap:1.5.0_12
      Code-Source: unknown
      Configuration: jre bootstrap

      This load was initiated at oc4j:11.1.1.0.0 using the Class.forName() method. The missing class is available from the following locations:

      1. Code-Source:
      /C:/JDEVADF_MAIN_GENERIC_080404.1239.4941/lib/java/shared/oracle.jstl/1.2/jstl
      -api-1_2.jar (from <code-source> (ignore manifest Class-Path) in
      /C:/jdevsystem/system11.1.1.0.22.49.41/o.j2ee/embedded-oc4j/config/server.xml)

      This code-source is available in loader oracle.jstl:1.2. This
      shared-library can be made visible to the "oc4j" loader by modifying the boot
      descriptor.

      at oracle.classloader.PolicyClassLoader.handleClassNotFound
      (PolicyClassLoader.java:2176)
      [/C:/JDEVADF_MAIN_GENERIC_080404.1239.4941/j2ee/home/lib/pcl.jar (from system
      property java.class.path), by sun.misc.Launcher$AppClassLoader@20120943]
      at oracle.classloader.PolicyClassLoader.internalLoadClass
      (PolicyClassLoader.java:1729)
      [/C:/JDEVADF_MAIN_GENERIC_080404.1239.4941/j2ee/home/lib/pcl.jar (from system
      property java.class.path), by sun.misc.Launcher$AppClassLoader@20120943]
      at oracle.classloader.PolicyClassLoader.loadClass
      (PolicyClassLoader.java:1685)
      [/C:/JDEVADF_MAIN_GENERIC_080404.1239.4941/j2ee/home/lib/pcl.jar (from system
      property java.class.path), by sun.misc.Launcher$AppClassLoader@20120943]
      at oracle.classloader.PolicyClassLoader.loadClass
      (PolicyClassLoader.java:1670)
      [/C:/JDEVADF_MAIN_GENERIC_080404.1239.4941/j2ee/home/lib/pcl.jar (from system
      property java.class.path), by sun.misc.Launcher$AppClassLoader@20120943]
      at java.lang.ClassLoader.loadClassInternal (ClassLoader.java:319) [jre
      bootstrap, by jre.bootstrap:1.5.0_12]
      at java.lang.Class.forName0 (Native method) [unknown, by unknown]
      at java.lang.Class.forName (Class.java:242) [jre bootstrap, by
      jre.bootstrap:1.5.0_12]
      at java.io.ObjectInputStream.resolveClass (ObjectInputStream.java:585) [jre
      bootstrap, by jre.bootstrap:1.5.0_12]
      at java.io.ObjectInputStream.readNonProxyDesc (ObjectInputStream.java:1544)
      [jre bootstrap, by jre.bootstrap:1.5.0_12]
      at java.io.ObjectInputStream.readClassDesc (ObjectInputStream.java:1466)
      [jre bootstrap, by jre.bootstrap:1.5.0_12]
      at java.io.ObjectInputStream.readOrdinaryObject
      (ObjectInputStream.java:1699) [jre bootstrap, by jre.bootstrap:1.5.0_12]
      at java.io.ObjectInputStream.readObject0 (ObjectInputStream.java:1305) [jre
      bootstrap, by jre.bootstrap:1.5.0_12]
      at java.io.ObjectInputStream.readObject (ObjectInputStream.java:348) [jre
      bootstrap, by jre.bootstrap:1.5.0_12]

      The issue is that ObjectInputStream created by CoreResponseStateManager uses default class loader instead of context class loader.

        Activity

        Matthias Weßendorf made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Andrew Robinson made changes -
        Resolution Fixed [ 1 ]
        Fix Version/s  1.0.8-core [ 12313040 ]
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Hide
        Andrew Robinson added a comment -

        Committed the patch with more comments

        Show
        Andrew Robinson added a comment - Committed the patch with more comments
        Hide
        Max Starets added a comment -

        WebLogic Tech Preview 10.3 - same exception as OC4J

        Show
        Max Starets added a comment - WebLogic Tech Preview 10.3 - same exception as OC4J
        Hide
        Andrew Robinson added a comment -

        I tested several different servers and here are my results:

        apache-tomcat-6.0.16 - working
        jboss AS 5.0.0.Beta4 - working
        jetty 6.1.7 - working
        JDev w/ OC4J development build 080501.0513.4973 - exception

        Looks like it may be an OC4J issue

        Show
        Andrew Robinson added a comment - I tested several different servers and here are my results: apache-tomcat-6.0.16 - working jboss AS 5.0.0.Beta4 - working jetty 6.1.7 - working JDev w/ OC4J development build 080501.0513.4973 - exception Looks like it may be an OC4J issue
        Hide
        Max Starets added a comment -

        You were looking at the doc on GNU site. Sun's Javadoc is actually different. They do not mention context classLoader:

        • <p>The default implementation of this method in
        • <code>ObjectInputStream</code> returns the result of calling
        • <pre>
        • Class.forName(desc.getName(), false, loader)
        • </pre>
        • where <code>loader</code> is determined as follows: if there is a
        • method on the current thread's stack whose declaring class was
        • defined by a user-defined class loader (and was not a generated to
        • implement reflective invocations), then <code>loader</code> is class
        • loader corresponding to the closest such method to the currently
        • executing frame; otherwise, <code>loader</code> is
        • <code>null</code>.
        Show
        Max Starets added a comment - You were looking at the doc on GNU site. Sun's Javadoc is actually different. They do not mention context classLoader: <p>The default implementation of this method in <code>ObjectInputStream</code> returns the result of calling <pre> Class.forName(desc.getName(), false, loader) </pre> where <code>loader</code> is determined as follows: if there is a method on the current thread's stack whose declaring class was defined by a user-defined class loader (and was not a generated to implement reflective invocations), then <code>loader</code> is class loader corresponding to the closest such method to the currently executing frame; otherwise, <code>loader</code> is <code>null</code>.
        Hide
        Max Starets added a comment -

        Haven't tried any container besides OC4J, so in theory this could be OC4J issue.

        Show
        Max Starets added a comment - Haven't tried any container besides OC4J, so in theory this could be OC4J issue.
        Hide
        Andrew Robinson added a comment -

        I am looking into this, and I do not see why this is needed

        The JDK implementation of resolveClass uses the current class loader:

        return VMObjectInputStream.currentClassLoader();

        See http://docjar.com/html/api/java/io/ObjectInputStream.java.html line 779

        In http://docjar.com/docs/api/java/io/VMObjectInputStream.html you will see this is defined as:

        Returns the first user defined class loader on the call stack, or the context class loader of the current thread, when no non-null class loader was found.

        As you can see, the code should already be using the correct class loader. Is it possible that this is an OC4J bug? Does it reproduce in Tomcat or Jetty or only OC4J?

        Show
        Andrew Robinson added a comment - I am looking into this, and I do not see why this is needed The JDK implementation of resolveClass uses the current class loader: return VMObjectInputStream.currentClassLoader(); See http://docjar.com/html/api/java/io/ObjectInputStream.java.html line 779 In http://docjar.com/docs/api/java/io/VMObjectInputStream.html you will see this is defined as: Returns the first user defined class loader on the call stack, or the context class loader of the current thread, when no non-null class loader was found. As you can see, the code should already be using the correct class loader. Is it possible that this is an OC4J bug? Does it reproduce in Tomcat or Jetty or only OC4J?
        Max Starets made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Max Starets made changes -
        Field Original Value New Value
        Attachment ObjectInputStream.diff [ 12381346 ]
        Max Starets created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Max Starets
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development