glassfish
  1. glassfish
  2. GLASSFISH-5212

Cannot run VisualJSF web app on latest V3 builds

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: V3
    • Fix Version/s: V3
    • Component/s: web_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      5,212

      Description

      I created a visual JSF app with NetBeans and tried to run it on a Jun 24 build
      of V3 (either OSGi mode or HK2 mode, doesn't matter).

      The application fails to load due to ClassNotFoundExceptions for classes that
      should be loaded from jars in the applications WEB-INF/lib folder, suggesting
      that web container is not properly loading such jars for the application.

        Activity

        Hide
        jluehe added a comment -

        Hi Hong, yes, the same WebappClassLoader instance is used during deployment
        descriptor/annotation processing and module startup, but only the latter will
        add the JAR files from WEB-INF/lib to the list of repositories that need to be
        searched during class loading. I know that in V2, the deployment backend used to
        create a temporary classloader from, amongst other things, the JAR files in
        WEB-INF/lib, in order to be able to process annotations, but this was creating
        its own set of problems, because different class definitions (for the same
        .class files) would be used for annotation processing and post-startup
        classloading.

        Show
        jluehe added a comment - Hi Hong, yes, the same WebappClassLoader instance is used during deployment descriptor/annotation processing and module startup, but only the latter will add the JAR files from WEB-INF/lib to the list of repositories that need to be searched during class loading. I know that in V2, the deployment backend used to create a temporary classloader from, amongst other things, the JAR files in WEB-INF/lib, in order to be able to process annotations, but this was creating its own set of problems, because different class definitions (for the same .class files) would be used for annotation processing and post-startup classloading.
        Hide
        Hong Zhang added a comment -

        Jan: Yes, we used to have a separate classloader for deployment in v2. It's good
        to have the same instance of the classloader in v3 for both deployment and
        starting.
        About your comment about "only the latter will add the JAR files from
        WEB-INF/lib to the list of repositories that need to be searched during class
        loading", can you clarify further?
        Looking at the WarHandler.getClassLoader method, it iterates through all the jar
        files under WEB-INF/lib and adds them to the classloader repository. Is there an
        extra step needed to actually make such repository searchable by the
        classloading (if so, can you point me to the code for this)? Otherwise the
        WEB-INF/lib jars should be available at the deployment time also..

        Show
        Hong Zhang added a comment - Jan: Yes, we used to have a separate classloader for deployment in v2. It's good to have the same instance of the classloader in v3 for both deployment and starting. About your comment about "only the latter will add the JAR files from WEB-INF/lib to the list of repositories that need to be searched during class loading", can you clarify further? Looking at the WarHandler.getClassLoader method, it iterates through all the jar files under WEB-INF/lib and adds them to the classloader repository. Is there an extra step needed to actually make such repository searchable by the classloading (if so, can you point me to the code for this)? Otherwise the WEB-INF/lib jars should be available at the deployment time also..
        Hide
        jluehe added a comment -

        Hi Hong,

        thanks for the WarHandler tip! I do see the JAR files from WEB-INF/lib being
        added to the WebappClassLoader in WarHandler.getClassLoader(), but
        they were being added using the wrong method: They should have been added using
        WebappClassLoader.addJar() instead of WebappClassLoader.addRepository(). This is
        one of those WebappClassLoader subtleties that I don't expect anybody outside of
        the Tomcat community to understand.

        I just committed this fix:

        Sending
        web/war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java
        Transmitting file data .
        Committed revision 21151.

        With my fix, all ClassNotFoundExceptions are gone, but I am seeing a new
        exception now, with this stacktrace:

        [#|2008-07-02T08:25:53.403+0800|SEVERE|GlassFish10.0|org.apache.catalina.startup.TldConfig|_ThreadID=13;_ThreadName=Thread-4;|PWC3036:
        Exception processing TLD META-INF/jsfcl.tld in JAR at resource path
        /space/luehe/ws/v3/distributions/web/target/glassfish/domains/domain1/applications/VisualWebJsf1/WEB-INF/lib/jsfcl.jar
        in context /VisualWebJsf1
        java.io.FileNotFoundException:
        http://java.sun.com/j2ee/dtd/web-jsptaglibrary_1_2.dtd
        at
        sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1168)
        at
        com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
        at
        com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905)
        at
        com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872)
        at
        com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282)
        at
        com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021)
        at
        com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
        at
        com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
        at
        com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
        at
        com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
        at
        com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
        at org.apache.commons.digester.Digester.parse(Digester.java:1548)
        at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:727)
        at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:658)
        at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:472)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:5260)

        I think this is related to Kohsuke's removal of
        org.apache.catalina.startup.DigesterFactory.setDtdResourcePrefix() when he added
        support for the Embedded API.

        Reassigning the bug to him.

        Thanks!

        Jan

        Show
        jluehe added a comment - Hi Hong, thanks for the WarHandler tip! I do see the JAR files from WEB-INF/lib being added to the WebappClassLoader in WarHandler.getClassLoader(), but they were being added using the wrong method: They should have been added using WebappClassLoader.addJar() instead of WebappClassLoader.addRepository(). This is one of those WebappClassLoader subtleties that I don't expect anybody outside of the Tomcat community to understand. I just committed this fix: Sending web/war-util/src/main/java/com/sun/enterprise/glassfish/web/WarHandler.java Transmitting file data . Committed revision 21151. With my fix, all ClassNotFoundExceptions are gone, but I am seeing a new exception now, with this stacktrace: [#|2008-07-02T08:25:53.403+0800|SEVERE|GlassFish10.0|org.apache.catalina.startup.TldConfig|_ThreadID=13;_ThreadName=Thread-4;|PWC3036: Exception processing TLD META-INF/jsfcl.tld in JAR at resource path /space/luehe/ws/v3/distributions/web/target/glassfish/domains/domain1/applications/VisualWebJsf1/WEB-INF/lib/jsfcl.jar in context /VisualWebJsf1 java.io.FileNotFoundException: http://java.sun.com/j2ee/dtd/web-jsptaglibrary_1_2.dtd at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1168) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905) at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872) at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at org.apache.commons.digester.Digester.parse(Digester.java:1548) at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:727) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:658) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:472) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5260) I think this is related to Kohsuke's removal of org.apache.catalina.startup.DigesterFactory.setDtdResourcePrefix() when he added support for the Embedded API. Reassigning the bug to him. Thanks! Jan
        Hide
        jluehe added a comment -

        ..

        Show
        jluehe added a comment - ..
        Hide
        jluehe added a comment -

        I've verified that the org.glassfish.web.WebEntityResolver that gets injected
        into the DigesterFactory is able to resolve web-jsptaglibrary_1_2.dtd locally.

        Not sure why this was failing earlier.

        As a side note, one of the TLDs (not sure which!) is using a wrong system id:

        http://java.sun.com/j2ee/dtd/web-jsptaglibrary_1_2.dtd

        which does not exist (see the FileNotFoundException in the stacktrace above).

        The correct URL is:

        http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd

        In any case, it seems my fix for the issue (before I assigned it to Kohsuke) was
        sufficient.

        Show
        jluehe added a comment - I've verified that the org.glassfish.web.WebEntityResolver that gets injected into the DigesterFactory is able to resolve web-jsptaglibrary_1_2.dtd locally. Not sure why this was failing earlier. As a side note, one of the TLDs (not sure which!) is using a wrong system id: http://java.sun.com/j2ee/dtd/web-jsptaglibrary_1_2.dtd which does not exist (see the FileNotFoundException in the stacktrace above). The correct URL is: http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd In any case, it seems my fix for the issue (before I assigned it to Kohsuke) was sufficient.

          People

          • Assignee:
            jluehe
            Reporter:
            peterwx
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: