aspose file tools*
The moose likes JBoss/WildFly and the fly likes deploying two identical webapps independently Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "deploying two identical webapps independently" Watch "deploying two identical webapps independently" New topic
Author

deploying two identical webapps independently

Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
i have two exploded wars that are identical except for a few configuration parameters.

if i deploy just one (put it under a.war directory in deploy directory) - all is fine

if i deploy both at the same time (a.war and b.war directories) - they influence each other and blow up

i have followed the following wiki entry:
http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

configuration:
- sun jdk 1.4.2_04
- jboss3.2.3

1. just deploying a.war

1.1 changing jbossweb-tomcat41.sar/META-INF/jboss-service.xml



result:

blows up - javax.servlet.ServletException: org/xml/sax/Attributes
although this file is present in a jar under WEB-INF/lib

1.2 changing jbossweb-tomcat41.sar/META-INF/jboss-service.xml



result:

blows up


1.3 changing jbossweb-tomcat41.sar/META-INF/jboss-service.xml



result:

blows up


1.4 created a.war/WEB-INF/jboss-web.xml with the following:



result:

blows up


1.5 tried 1.4 with 1.1-1.3

result:

blows up

1.6 put a.war into a.ear, put b.war into b.ear

created application.xml:


and jboss-app.xml


same with b.ear/b.war, with proper changes

result: blows up with javax.servlet.ServletException: org/xml/sax/Attributes


i am very-very confused. thank you for your help
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
I'm gonna try that out. Is there anything you could send me to help out? like are you using classes, jars, jsp's?

When things "blow up" is it because they affected each other, or they blew up individually?


It's almost Friday
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
Also, in the mean time, would putting your xml jar in the main deployer (the deploy directory) fix that?
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
Originally posted by Jeff Shelley:
Also, in the mean time, would putting your xml jar in the main deployer (the deploy directory) fix that?


war is in the exploded format
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
Originally posted by Jeff Shelley:
I'm gonna try that out. Is there anything you could send me to help out? like are you using classes, jars, jsp's?

When things "blow up" is it because they affected each other, or they blew up individually?


if i drop the exploded war into the deploy directory, it works just fine.
then, in preparation for the co-existing apps, i try to make one single exploded war work with various classloading schemes. that fails.
next, i try two exploded wars - the result is the same.

the app is snipsnap 0.5.1a ( http://snipsnap.org/ )

please see the stacktrace below:


[ June 24, 2004: Message edited by: x0r ]
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
i think the problem is that the wars need to be loaded via two completely isolated classloaders that share nothing with each other. however, when i try to configure that, it fails to find existing libraries bundled with the app.
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
What Request URI caused your error? I had always thought that the jars in lib directories in web archives were treated differently than jars in ears.
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
Originally posted by Jeff Shelley:
What Request URI caused your error? I had always thought that the jars in lib directories in web archives were treated differently than jars in ears.


just accessing the app's front page (or any page for that matter).

that is if it actually got deployed, in most cases, when i tried the configuration above, it won't even deploy the app (i did not hotdeploy, restarting the server with each config change).

below is the typical example of such behavior:

Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
ok. I was able to deploy both of them.

My jboss-service.xml doesn't have any of those
Java2ClassLoadingCompliance or UseJBossWebLoader settings anywhere.

I didn't need to mess with war scoped loading either.

but then again. I wasn't able to find version 0.5.1a, so I used 0.5.2a.

Do you think your distribution could have become corrupted during your download?
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
Originally posted by Jeff Shelley:
ok. I was able to deploy both of them.

My jboss-service.xml doesn't have any of those
Java2ClassLoadingCompliance or UseJBossWebLoader settings anywhere.

I didn't need to mess with war scoped loading either.

but then again. I wasn't able to find version 0.5.1a, so I used 0.5.2a.

Do you think your distribution could have become corrupted during your download?


thank you for your response.

did you deploy, or deploy+configured both of them, since there is a setup process that an instance goes through?

i have to admit, i have not tried the new version yet, since there was a considerable investment into tweaking the old one.

as for corruption, each of the exploded wars works fine by itself, with the default jboss settings.
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
I had not configured it. That's giving me some error from some InitFilter.

org.picocontainer.defaults.DuplicateComponentKeyRegistrationException:
Key class org.snipsnap.container.MessageLogService duplicated
at org.picocontainer.defaults.DefaultPicoContainer.registerComponent(DefaultPicoContainer.java:80)
at org.picocontainer.defaults.DefaultPicoContainer.registerComponentImplementation(DefaultPicoContainer

at org.picocontainer.defaults.DefaultPicoContainer.registerComponentImplementation(DefaultPicoContainer

at org.picocontainer.defaults.DefaultPicoContainer.registerComponentImplementation(DefaultPicoContainer

at org.snipsnap.container.Components.getContainer(Components.java:133)
at org.snipsnap.container.Components.getComponent(Components.java:149)
at org.snipsnap.net.filter.InitFilter.doFilter(InitFilter.java:237)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:509)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.j

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.jav

at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:534)


So I'll have to play with that for a while.
[ June 24, 2004: Message edited by: Jeff Shelley ]
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
Originally posted by Jeff Shelley:
I had not configured it. That's giving me some error from some InitFilter.

org.picocontainer.defaults.DuplicateComponentKeyRegistrationException:
Key class org.snipsnap.container.MessageLogService duplicated
at org.picocontainer.defaults.DefaultPicoContainer.registerComponent(DefaultPicoContainer.java:80)
at org.picocontainer.defaults.DefaultPicoContainer.registerComponentImplementation(DefaultPicoContainer

So I'll have to play with that for a while.

[ June 24, 2004: Message edited by: Jeff Shelley ]




right, this means that they influence each other (duplicate key registration). this is when i started playing with UCL to see if i can isolate the two.
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
actually, man, it happens to me when there's only one deployed. So I don't know. This is getting fun, though.
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
i just tried leaving the working 0.5.1a instance in deploy directory as exploded war file, and adding a new 0.5.2a instance.

1. 0.5.2a as an exploded war - they influence each other, no go
2. 0.5.2a as an exploded war within an xxx.ear directory - they still influence each other, no go
3. 0.5.2a as an exploded war within an xxx.ear directory with modified jboss-app.xml (see code block above) - it loaded both apps fine, registered keys and all, the old 0.5.1a works just great, but when i tried to hit and configure new 0.5.2a, it dies with the exception below. this means, that i was successfully able to isolate the two apps, however, i cannot get the isolated one to run properly.


[ June 24, 2004: Message edited by: x0r ]
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
Originally posted by Jeff Shelley:
actually, man, it happens to me when there's only one deployed. So I don't know. This is getting fun, though.


just to make sure - do not use hot deploy
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
Still getting it without hot deploy. I cranked log4j to trace and made sure there was no category limiting, and surprise surprise, I don't get any more information than before.
Andy Page
Greenhorn

Joined: Jul 29, 2002
Posts: 21
it would be nice if someone could point me to a good doc, explaining in details the way classloading is affected by the settings i've tried, as well as a good explanation of jboss 3.2.3 classloading mechanism and possible causes of my errors.

so far i went through the jboss forums, got the latest $10 book, read the getting started and the wiki.

thanks
Jeff Shelley
Ranch Hand

Joined: May 21, 2003
Posts: 70
here you go. http://sourceforge.net/docman/?group_id=22866
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: deploying two identical webapps independently