Search...
FAQs Subscribe
Pie
FAQs
Recent topics Flagged topics Hot topics Best topics
Search...
Search within JBoss/WildFly Search Coderanch
Advance search Google search
Register / Login
granny thread boost book review grid polymorphism advertise on coderanch
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
meaningless drivel thread boost book review grid building better world book advertise on coderanch
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Tim Cooke
  • Devaka Cooray
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
Bartenders:
  • Carey Brown
  • Roland Mueller

deploying two identical webapps independently

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
Also, in the mean time, would putting your xml jar in the main deployer (the deploy directory) fix that?

It's almost Friday

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

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
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

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
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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.

It's almost Friday

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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?

It's almost Friday

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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 ]

It's almost Friday

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
actually, man, it happens to me when there's only one deployed. So I don't know. This is getting fun, though.

It's almost Friday

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator

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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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.

It's almost Friday

 
Andy Page
Greenhorn
Posts: 21
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
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
Posts: 70
posted 20 years ago
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
    Send
  • Quote
  • Report post to moderator
here you go. http://sourceforge.net/docman/?group_id=22866

It's almost Friday

 
I don't like that guy. The tiny ad agrees with me.
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
reply
    Bookmark Topic Watch Topic
  • New Topic
Boost this thread!
Similar Threads
More...