1 2 Previous Next 26 Replies Latest reply on Sep 16, 2009 6:23 AM by alesj

    Exploding jar libraries in deployments

    jaikiran

      Having an archived war file in AS-5.1.0 (Branch_5_x and trunk) which contains jar files in the WEB-INF/lib folder of the war leads to these jars being exploded to tmp folder too. Any specific reason why we are exploding the jars in the lib folder of the war? My understanding was that (like AS 4.x) we would explode just the war file (deployment) and not the libraries contained in the deployment.

      myapp.war (archived)
      |
      |--- WEB-INF
      | |
      | |--- lib
      | | |--- myapp.jar
      
      


      The side effect of exploding the library jar files is that it can lead to the deployment to fail, because there's some deployment code (in tomcat) which expects these libraries to be archived jar files:

      12:36:24,050 ERROR [TldConfig] Exception processing JAR at resource path /home/jpai/jbossas/branches/Branch_5_x/build/output/jboss-5.2.0.Beta/server/default/tmp/3j001-wsysts-fxwux83v-1-fxwuy9zz-9p/myapp-isolation-test.war/WEB-INF/lib/myapp.jar in context /myapp-isolation-test
      java.util.zip.ZipException: error in opening zip file
       at java.util.zip.ZipFile.open(Native Method)
       at java.util.zip.ZipFile.<init>(ZipFile.java:203)
       at java.util.jar.JarFile.<init>(JarFile.java:132)
       at java.util.jar.JarFile.<init>(JarFile.java:97)
       at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:461)
       at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301)
       at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4540)
       at org.apache.catalina.core.StandardContext.start(StandardContext.java:4308)
       at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
       at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
       at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462)
       at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
       at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
       at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
       at org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:283)
       at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
       at $Proxy38.start(Unknown Source)
       at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
       at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
       at
      ...//trimmed irrelevant stacktrace
      



      By the way, where does the code which does the tmp file exploding reside? Is it in AS or some MC component?


        • 1. Re: Exploding jar libraries in deployments
          alesj

           

          "jaikiran" wrote:

          By the way, where does the code which does the tmp file exploding reside? Is it in AS or some MC component?

          It's in AS:
          - http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java
          It uses VFS unjar mechanism, which actually uses the same unjar mechanism as 4.x - part of Common-core.
          Hence I don't see how this could be different, 5.x vs. 4.x.


          • 2. Re: Exploding jar libraries in deployments
            alesj

             

            "alesj" wrote:
            Hence I don't see how this could be different, 5.x vs. 4.x.

            Ah, a small detail that was recently changed by ALR:
            - http://fisheye.jboss.org/changelog/JBossAS/branches/Branch_5_x/server/src/main/org/jboss?cs=91311
            So, there is your culprit. ;-)

            • 3. Re: Exploding jar libraries in deployments
              jaikiran

               

              "alesj" wrote:

              Ah, a small detail that was recently changed by ALR:
              - http://fisheye.jboss.org/changelog/JBossAS/branches/Branch_5_x/server/src/main/org/jboss?cs=91311
              So, there is your culprit. ;-)


              You found it! :) ALR has this related forum thread http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158515. I'll comment there.

              Having an archived war file in AS-5.1.0...


              My bad doesn't seem to affect 5.1.0 released version. My AS 5.1.0 version is messed up with all local patches :) The change only affects the Branch 5_x and trunk.


              • 4. Re: Exploding jar libraries in deployments
                alrubinger

                So it looks like we instead need some non-recursive "explode". Or at least a mechanism like "unjar" which will act upon vfsmemory.

                Any preference Ales? Or you'd prefer we handle it outside of jboss-vfs and hack something together just for Tomcat?

                S,
                ALR

                • 5. Re: Exploding jar libraries in deployments
                  alrubinger

                  BTW is there a failing test case for this ATM?

                  S,
                  ALR

                  • 6. Re: Exploding jar libraries in deployments
                    jaikiran

                     

                    "ALRubinger" wrote:
                    BTW is there a failing test case for this ATM?



                    I'll create a JIRA for this and attach the testcase.


                    • 7. Re: Exploding jar libraries in deployments
                      alesj

                       

                      "ALRubinger" wrote:

                      Any preference Ales? Or you'd prefer we handle it outside of jboss-vfs and hack something together just for Tomcat?

                      What about if you just extracted that line,
                      and then override it in your custom EmbInMemWarDeployer?

                      • 8. Re: Exploding jar libraries in deployments
                        alrubinger

                         

                        "alesj" wrote:
                        What about if you just extracted that line,
                        and then override it in your custom EmbInMemWarDeployer?


                        That violates a design goal of Embedded.

                        Embedded is a combination of projects which launch AS inside an existing process. Any time AS itself cannot handle being run in a fashion other than standalone points to improper assumptions it makes about its environment.

                        I'd instead like to overload AbstractCopyMechanism with a non-recursive explode(), and expose that via VFSUtils.

                        S,
                        ALR

                        • 9. Re: Exploding jar libraries in deployments
                          alrubinger
                          • 10. Re: Exploding jar libraries in deployments
                            alesj

                             

                            "ALRubinger" wrote:
                            I'd instead like to overload AbstractCopyMechanism with a non-recursive explode(), and expose that via VFSUtils.

                            What exactly is your use case?
                            A mixture of in-memory and normal files?

                            Perhaps all that's required is that VFSUtils::unjar returns same ref
                            if the original file param is not backed by plain file handler.
                            e.g. like in your case where that's in-memory

                            • 11. Re: Exploding jar libraries in deployments
                              alrubinger

                               

                              "alesj" wrote:
                              What exactly is your use case?
                              A mixture of in-memory and normal files?


                              Tomcat must unjar the root deployment. This means that we need some equivalent which can handle vfsmemory (as explode() does, though without the recursion).

                              Perhaps all that's required is that VFSUtils::unjar returns same ref
                              if the original file param is not backed by plain file handler.
                              e.g. like in your case where that's in-memory


                              That was the original problem. unjar() originally had no effect upon vfsmemory.

                              Thinking some more, seems for nested vfsmemory archives: the root should be unpacked/serialized to plain files and the nested ones should be as well...but not nested JARs (which are left intact).

                              S,
                              ALR

                              • 12. Re: Exploding jar libraries in deployments
                                alesj

                                 

                                "ALRubinger" wrote:

                                That was the original problem. unjar() originally had no effect upon vfsmemory.

                                No, the original problem is that Tomcat code even demands such unjaring,
                                which is overhead in the case of VFS.

                                But from reading Remy's Servlet3 TODOs, this shouldn't be the case anymore,
                                as the default Context impl will be VFS based.

                                "ALRubinger" wrote:

                                Thinking some more, seems for nested vfsmemory archives: the root should be unpacked/serialized to plain files and the nested ones should be as well...but not nested JARs (which are left intact).

                                This looks like a hack to handle something that was never expected to work in JBWeb code.
                                You should fix the real problem and not hack around something that is already a hack to fix a hack. ;-)
                                e.g. check what it takes to get JBW's VFSContext back

                                • 13. Re: Exploding jar libraries in deployments
                                  alrubinger

                                   

                                  "alesj" wrote:
                                  No, the original problem is that Tomcat code even demands such unjaring, which is overhead in the case of VFS.


                                  Well, that gets back to the original, original problem. But I'm not going to be getting a fix for that in Branch_5_x, nor can I go off in tangents everytime something in AS doesn't quite support running Embedded. My proposal for a non-recursive explode() is a stopgap in order to get a release out in time for JBW in early September. I don't believe the feature request is in itself a hack.

                                  "alesj" wrote:
                                  But from reading Remy's Servlet3 TODOs, this shouldn't be the case anymore, as the default Context impl will be VFS based.


                                  Yes, this should be the trunk migration path looking forward.

                                  "alesj" wrote:
                                  "ALRubinger" wrote:
                                  Thinking some more, seems for nested vfsmemory archives: the root should be unpacked/serialized to plain files and the nested ones should be as well...but not nested JARs (which are left intact).

                                  This looks like a hack to handle something that was never expected to work in JBWeb code.
                                  You should fix the real problem and not hack around something that is already a hack to fix a hack. ;-)
                                  e.g. check what it takes to get JBW's VFSContext back


                                  For Servlet 3.0 and getting true components into AS, yes. But I can't dedicate time into working around the design of the current web module, or the flat file requirement, for Embedded now. We make it work, then we make it work well.

                                  S,
                                  ALR

                                  • 14. Re: Exploding jar libraries in deployments
                                    jason.greene

                                    ALR,

                                    Why don't you just switch from vfsmrmory to using a file based VFS on a temp location for now, until we see what happens with VFS in trunk?

                                    1 2 Previous Next