7 Replies Latest reply on Jan 16, 2004 3:51 PM by Juha Lindfors

    Classpath clash between webapps

    mprivat Newbie

      I am deploying two different webapps as two WAR files. Both of them read their respective configuration from a resource called config/services.xml

      The file is placed under the WEB-INF/classes/ folder in each WAR file. Deploying one WAR works fine, but when I deploy the second one, it finds the configuration file from the first WAR file, instead of its own !?

      So it looks to me like the server is using the same classloader for both webapps. Is there any way to avoid this?

      Thanks to anyone who can help.
      Michael

        • 1. Re: Classpath clash between webapps
          Juha Lindfors Master

          What if you set "UseJBossWebLoader" in your deploy/jbossweb-tomcat/META-INF/jboss-service.xml to false?

          • 2. Re: Classpath clash between webapps
            Dmitry Sklyut Newbie

             

            "dsklyut" wrote:
            Don't use UseJBossWebLoader = false if you use the EJB. This will make use RMI to call them... Just add something like that in your jboss-web.xml and that should cover your issues:

            <class-loading java2ClassLoadingCompliance='false'>
            <loader-repository loaderRepositoryClass='dot.com.LoaderRepository'>
            dot.com:loader=mywar.war
            </loader-repository>
            </class-loading>


            • 3. Re: Classpath clash between webapps
              mprivat Newbie

              Thanks for all the suggestions. I hate to sound stupid, but where is the jboss-web.xml syntax documented? I have no idea what to put in there and I am assuming the snippet you gave is an extract nested in another tag.

              Michael

              • 4. Re: Classpath clash between webapps
                micke Novice

                The DTD can be found in JBOSS_HOME\docs\dtd

                • 5. Re: Classpath clash between webapps
                  Juha Lindfors Master

                   

                  "juha@jboss.org" wrote:
                  "dsklyut" wrote:
                  Don't use UseJBossWebLoader = false if you use the EJB. This will make use RMI to call them...


                  Umm, no. UseJBossWebLoader just controls the visibility of an UCL loader into a WAR's WEB-INF directory.

                  Isolating two deployments into two loader repositories however will force you to serialize any calls between the deployments in the separate repositories.



                  • 6. Re: Classpath clash between webapps
                    Dmitry Sklyut Newbie

                     

                    "dsklyut" wrote:
                    "juha@jboss.org" wrote:

                    Umm, no. UseJBossWebLoader just controls the visibility of an UCL loader into a WAR's WEB-INF directory.

                    Isolating two deployments into two loader repositories however will force you to serialize any calls between the deployments in the separate repositories.



                    I beg to disagree with you on that. Just went throug a very extensive testing cycle with my deployment. UseJbossWebLoader=false will force the Tomcat WebLoader to be used. Isolation on the other hand just marks a Loader Repository in the same ClassLoader.

                    If that statment is not how it is supposed to work, than you gots yourself a bug there brother...
                    I couldn't really find any documentation on how the UseJBossWebLoader is supposed to work. But there is enough info on the loader-repositories. And loader repository is just a UCL for the classes loaded by a ClassLoader at a deployment level. There is still parent delegation in place here.

                    Also, maybe I misunderstood the original post. mprivat had two web apps that must use the same classes and cooexist in the same JBoss server instance. So isolating only the web tier does not explicitly states that web classes can't look into the main UCL if classes are not found in the loader-repository. EJBs can be deployed separatly and they will reside in the main UCL visible to all an any.

                    Dmitry


                    • 7. Re: Classpath clash between webapps
                      Juha Lindfors Master

                       

                      "dsklyut" wrote:

                      I beg to disagree with you on that. Just went throug a very extensive testing cycle with my deployment. UseJbossWebLoader=false will force the Tomcat WebLoader to be used.


                      Which has an UCL as its parent from the thread context classloader.


                      "dsklyut" wrote:

                      Isolation on the other hand just marks a Loader Repository in the same ClassLoader.


                      Classloaders in separate repositories do not have reference visibility to each other.

                      "dsklyut" wrote:

                      If that statment is not how it is supposed to work, than you gots yourself a bug there brother...


                      Ok, then submit a bug report, brother...

                      "dsklyut" wrote:

                      I couldn't really find any documentation on how the UseJBossWebLoader is supposed to work.


                      Like I said earlier, it adds visibility into a WAR's WEB-INF directory from within a classloader repository. So in case of two WAR deployments the WEB-INF is shared.


                      "dsklyut" wrote:

                      And loader repository is just a UCL for the classes loaded by a ClassLoader at a deployment level.


                      Repository is not an UCL, it collects UCLs.


                      "dsklyut" wrote:

                      Also, maybe I misunderstood the original post. mprivat had two web apps that must use the same classes and cooexist in the same JBoss server instance.


                      I think the problem was restricting WAR's visibility in another WAR's WEB-INF directory where the configuration lies that was not supposed to be shared (i.e. 3.2.1 behavior).

                      Isolating the entire WAR will do the trick, but seems a bit heavy handed in such a case.