Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 5.0.18
    • Fix Version/s: None
    • Component/s: tapestry-ioc
    • Labels:
      None

      Description

      The class loaders of JBoss 5.x use URLs like

      vfszip:/M:/jboss/jboss-5.0.1.GA/server/default/deploy/tapestry-test.war/WEB-INF/lib/tapestry-core-5.0.18.jar/org/apache/tapestry5/corelib/pages/
      

      to point at class path resources. Tapestry is currently not capable of parsing these and as a result fails to find its own core components.

      This is related to the mail thread JBoss5 and T5 configuration? a collegue of mine found. The approach outlined there yields URLs that point at non-existent files but served as an inspiration for our patch.

      1. TAP5-576.patch
        2 kB
        Benjamin Bentmann

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          The attached patch converts the original URL
          vfszip:/M:/jboss/jboss-5.0.1.GA/server/default/deploy/tapestry-test.war/WEB-INF/lib/tapestry-core-5.0.18.jar/org/apache/tapestry5/corelib/pages/
          to something like
          jar:file:/M:/jboss/jboss-5.0.1.GA/server/default/tmp/5c4o4yq-x075nh-fs6e47em-1-fs6gfy75-9w/tapestry-test.war/WEB-INF/lib/tapestry-core-5.0.18.jar!/org/apache/tapestry5/corelib/pages
          which can be parsed by ClassNameLocatorImpl as usual.

          The patch uses reflection to get the real URL from the JBoss internals. Not beauty, but avoids the need to manually parse the URL and unpack the nested archives. Probably not the final solution but a starting point for others. Until Tapestry itself is fixed, users can insert this code into a custom ClasspathURLConverter as described in the mail thread.

          Show
          Benjamin Bentmann added a comment - The attached patch converts the original URL vfszip:/M:/jboss/jboss-5.0.1.GA/server/default/deploy/tapestry-test.war/WEB-INF/lib/tapestry-core-5.0.18.jar/org/apache/tapestry5/corelib/pages/ to something like jar: file:/M:/jboss/jboss-5.0.1.GA/server/default/tmp/5c4o4yq-x075nh-fs6e47em-1-fs6gfy75-9w/tapestry-test.war/WEB-INF/lib/tapestry-core-5.0.18.jar!/org/apache/tapestry5/corelib/pages which can be parsed by ClassNameLocatorImpl as usual. The patch uses reflection to get the real URL from the JBoss internals. Not beauty, but avoids the need to manually parse the URL and unpack the nested archives. Probably not the final solution but a starting point for others. Until Tapestry itself is fixed, users can insert this code into a custom ClasspathURLConverter as described in the mail thread.
          Hide
          Benjamin Bentmann added a comment -

          To give some more reference: The reflective method invocations are based on the sources for jboss-vfs-2.1.0.GA: http://repository.jboss.com/maven2/org/jboss/jboss-vfs/2.1.0.GA/

          Show
          Benjamin Bentmann added a comment - To give some more reference: The reflective method invocations are based on the sources for jboss-vfs-2.1.0.GA: http://repository.jboss.com/maven2/org/jboss/jboss-vfs/2.1.0.GA/
          Hide
          Igor Drobiazko added a comment -

          Sorry, but tapestry-ioc is not the proper place for that code. The service ClasspathURLConverter was introduced to solve such issues. Just override it in you application and that's it. I'm also overriding this service in my OSGi apps because in Equinox all classes have the protocol bundelresource.

          Show
          Igor Drobiazko added a comment - Sorry, but tapestry-ioc is not the proper place for that code. The service ClasspathURLConverter was introduced to solve such issues. Just override it in you application and that's it. I'm also overriding this service in my OSGi apps because in Equinox all classes have the protocol bundelresource.
          Hide
          Howard M. Lewis Ship added a comment -

          We already are making some special cases for Tomcat classpath loading, I can see making a case for JBoss as well.

          Show
          Howard M. Lewis Ship added a comment - We already are making some special cases for Tomcat classpath loading, I can see making a case for JBoss as well.
          Hide
          Howard M. Lewis Ship added a comment -

          Alternately, provide this is a plugin in a tapestry.formos.com project. I just don't like all those JBoss users thinking Tapestry is broken (though if they've used JBoss for a few years, they probably know where to start laying blame!)

          Show
          Howard M. Lewis Ship added a comment - Alternately, provide this is a plugin in a tapestry.formos.com project. I just don't like all those JBoss users thinking Tapestry is broken (though if they've used JBoss for a few years, they probably know where to start laying blame!)
          Hide
          Benjamin Bentmann added a comment -

          As a minimum, an update to the documentation could be helpful. From http://tapestry.apache.org/tapestry5/jboss.html:

          JBoss's default servlet container is Tomcat, so deployment notes for Tomcat apply to JBoss as well.

          That doesn't seem accurate AFAICT.

          Show
          Benjamin Bentmann added a comment - As a minimum, an update to the documentation could be helpful. From http://tapestry.apache.org/tapestry5/jboss.html: JBoss's default servlet container is Tomcat, so deployment notes for Tomcat apply to JBoss as well. That doesn't seem accurate AFAICT.

            People

            • Assignee:
              Unassigned
              Reporter:
              Benjamin Bentmann
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development