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

Exploding jar libraries in deployments

jaikiran Aug 3, 2009 3:50 AM

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 Aug 3, 2009 4:59 AM (in response to jaikiran)

"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.
Actions
2. Re: Exploding jar libraries in deployments

alesj Aug 3, 2009 5:00 AM (in response to jaikiran)

"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. ;-)
Actions
3. Re: Exploding jar libraries in deployments

jaikiran Aug 3, 2009 5:21 AM (in response to 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.
Actions
4. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 8:39 AM (in response to jaikiran)

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
Actions
5. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 8:41 AM (in response to jaikiran)

BTW is there a failing test case for this ATM?

S,
ALR
Actions
6. Re: Exploding jar libraries in deployments

jaikiran Aug 3, 2009 8:48 AM (in response to jaikiran)

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

I'll create a JIRA for this and attach the testcase.
Actions
7. Re: Exploding jar libraries in deployments

alesj Aug 3, 2009 9:08 AM (in response to jaikiran)

"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?
Actions
8. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 9:28 AM (in response to jaikiran)

"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
Actions
9. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 9:28 AM (in response to jaikiran)

Jaikiran's opened:

https://jira.jboss.org/jira/browse/JBAS-7148

S,
ALR
Actions
10. Re: Exploding jar libraries in deployments

alesj Aug 3, 2009 10:15 AM (in response to jaikiran)

"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
Actions
11. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 2:59 PM (in response to jaikiran)

"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
Actions
12. Re: Exploding jar libraries in deployments

alesj Aug 3, 2009 3:35 PM (in response to jaikiran)

"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
Actions
13. Re: Exploding jar libraries in deployments

alrubinger Aug 3, 2009 4:07 PM (in response to jaikiran)

"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
Actions
14. Re: Exploding jar libraries in deployments

jason.greene Aug 3, 2009 5:02 PM (in response to jaikiran)

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?
Actions

1 2 Previous Next

Go to original post