8 Replies Latest reply on Jan 22, 2010 6:26 PM by Dean Hiller

    Info required about jboss-classloading.xml

    djordjevs Newbie

      Good day,

      I've been working on migration from jboss as4 to jboss as5 and hit the as5 specific classloading problem with my ejb's where the third party jars referenced by ejbs are not loaded because they are also found in the server's top level lib directory and the server is loading those (example trove.jar) rather than ones that are part of the application. The problems is the versions of jars we use are different from the ones that come with the server, which breaks the app. I tried older style java2parentDelegation in jboss-app.xml which did not work at all in as5. After a lot of digging it appears I should be using jboss-classloading.xml but I could not find a place where the schema is explained. Just to reiterate it is ejb jar I have problems with not a war application for which there are some examples around (not sure if they work). So I've got two questions that I think a lot of people trying to use jboss as5 would like to see answered:


      1. Is it jboss-classloading.xml that I should be using in as 5 to isolate my ear/ejb app from the same jar that come with the server?

      2. Where can we find some documentation explaining how to define jboss-classloading.xml i.e. what are the meanings of tags?


      Thanks and I apologise if I posted this in a wrong spot.
      SDJ

        • 1. Re: Info required about jboss-classloading.xml
          Ales Justin Master

           

          "djordjevs" wrote:

          1. Is it jboss-classloading.xml that I should be using in as 5 to isolate my ear/ejb app from the same jar that come with the server?

          Yes.

          But the old config files should be still working,
          hence can you post your example to our JBoss5 forum.
          I know we had some issues, dunno how much Jaikiran tested it.

          "djordjevs" wrote:

          2. Where can we find some documentation explaining how to define jboss-classloading.xml i.e. what are the meanings of tags?

          https://jira.jboss.org/jira/browse/JBCL-10
          http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/src/main/java/org/jboss/classloading/spi/metadata/ClassLoadingMetaData10.java
          https://www.jboss.org/community/wiki/JBoss5custommetadatafiles
          http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5
          http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/deployer/src/main/java/org/jboss/webbeans/integration/deployer/metadata/WebBeansClassloadingDeployer.java

          • 2. Re: Info required about jboss-classloading.xml
            jaikiran pai Master

            As Ales mentions, although its recommended to use jboss-classloading.xml in AS5, using jboss-app.xml should perfectly work fine too.


            I've been working on migration from jboss as4 to jboss as5 and hit the as5 specific classloading problem with my ejb's where the third party jars referenced by ejbs are not loaded because they are also found in the server's top level lib directory and the server is loading those (example trove.jar) rather than ones that are part of the application.


            Where exactly are those jars placed? You can place such thirdparty jars in EAR/lib folder and use the jboss-app.xml to isolate/scope the classloaders (as you did in AS-4.x).

            I know we had some issues, dunno how much Jaikiran tested it.


            From what i tested, the jboss-app.xml works perfect. It's only the usage of jboss-web.xml for classloading configuration which seems to be running into issues (for some users) and which i need to test a bit more to come to a conclusion :)


            • 3. Re: Info required about jboss-classloading.xml
              djordjevs Newbie

              Hi,

              Thanks for the prompt response.

              The deploy is an ear file that contains an ejb jar, a war file and a sar file. All three files and the ear file contain only metadata - xml files (ejb.xml, web.xml etc. in the correct places) and no code at all. The application code is deployed in a jar and placed to ...../default/lib where are also all the third party libraries. This is how it's been done for years with no issues, up until upgrade to V5 (currently running on 4.0.2).

              The traditional ear deploy with java2parentDelegation does work as well as exploded deploy that I might use as a workaround, though I would prefer using jboss-classloading.xml.

              On that note, jboss-classloading.xml is still a mystery, the links provided really don't help much. A short document explaining at minimum the following would be highly appreciated.
              1. The xml structure - tags.
              2. What values should be put in the tags.
              3. Where the jboss-classloading.xml should be placed.

              Conclusion:
              1. I've got a workaround for the problem.
              2. It would be nice if at least some minimal documentation is provided for the new metadata files.


              Thanks again
              SDJ

              • 4. Re: Info required about jboss-classloading.xml
                null null Novice

                does the old method(jboss-web.xml and jboss-app.xml) work for this use case...

                 

                war1 and war2 use version 2 xx.jar (all in deploy directory)

                war1 uses version 2 of yy.jar (all in deploy directory)

                war2 uses version 1 of yy.jar (all in deploy directory)

                 

                I was under the impression OSGi supports this while old jboss unified classloader doesn't...in face, version2 of yy.jar will override(be loaded first) version 1 yy.jar(or vice versa).  Don't I have to use the new classloading.xml way and where are the details of that(xsd and location of file...i assume META-INF in jar files and WEB-INF in war files????)

                 

                thanks,

                Dean

                • 5. Re: Info required about jboss-classloading.xml
                  Ales Justin Master

                  Don't I have to use the new classloading.xml way and where are the details of that(xsd and location of file...

                  Some more info:

                  * http://www.jboss.org/community/docs/DOC-13178

                  * http://java.dzone.com/articles/jboss-microcontainer-classloading

                   

                  But this also means your other two - yy.jar v1 and v2 - need to have this jboss-classloading.xml as well.

                   

                  i assume META-INF in jar files and WEB-INF in war files?

                   

                  Yes.

                  • 6. Re: Info required about jboss-classloading.xml
                    null null Novice

                    I had used that first posting already which didn't work or seem to be enough.  I like that second article....THANKS.

                     

                    anyone have an existing jar that deploys successfully in 5.1.0 that i can compare mine with.

                     

                    Also, Do I have to use the new classloading.xml way for that example I gave.....I assume yes?

                     

                    I am however still running into a NullPointerException.  I removed my wars and just deploy my EJB3 jar with this file

                     

                    <classloading xmlns="urn:jboss:classloading:1.0">
                      <capabilities>
                        <module name="xcore3.jar"/>
                      </capabilities>
                    </classloading>

                     

                    I just want this xcore3.jar to be a supplier to two other war files basically, but just deploying this one jar, I get the below exception in jboss 5.1.0......

                     

                    2010-01-21 08:33:56,590 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (main) N/A Error installing to Real: name=vfszip:/home/jboss/jboss-5.1.0.GA/server/all/deploy/xcore3.jar/ state=PreReal mode=Manual requiredState=Real
                    org.jboss.deployers.spi.DeploymentException: Error deploying xcore3.jar: failed to initialize bean container
                        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196)
                        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99)
                        at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
                        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
                        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
                        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
                        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
                        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
                        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
                        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
                        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
                        at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
                        at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
                        at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
                        at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
                        at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
                        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                        at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
                        at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
                        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
                        at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
                        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
                        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
                        at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
                        at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
                        at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
                        at org.jboss.Main.boot(Main.java:221)
                        at org.jboss.Main$1.run(Main.java:556)
                        at java.lang.Thread.run(Thread.java:619)
                    Caused by: java.lang.RuntimeException: failed to initialize bean container
                        at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:253)
                        at org.jboss.ejb3.session.SessionContainer.<init>(SessionContainer.java:119)
                        at org.jboss.ejb3.session.SessionSpecContainer.<init>(SessionSpecContainer.java:69)
                        at org.jboss.ejb3.stateless.StatelessContainer.<init>(StatelessContainer.java:112)
                        at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
                        at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:203)
                        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:718)
                        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:669)
                        at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:651)
                        at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:614)
                        at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:491)
                        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:182)
                        ... 33 more
                    Caused by: java.lang.IllegalStateException: Null beannMetaData
                        at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.setupMetaDataLists(BeanInterceptorMetaDataBridge.java:315)
                        at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.initialise(BeanInterceptorMetaDataBridge.java:235)
                        at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.<init>(BeanInterceptorMetaDataBridge.java:138)
                        at org.jboss.ejb3.interceptors.metadata.AdditiveBeanInterceptorMetaDataBridge.<init>(AdditiveBeanInterceptorMetaDataBridge.java:48)
                        at org.jboss.ejb3.aop.BeanContainer.initialize(BeanContainer.java:194)
                        at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:249)
                        ... 44 more
                    Caused by: java.lang.NullPointerException
                        at org.jboss.ejb3.interceptors.metadata.BeanInterceptorMetaDataBridge.setupMetaDataLists(BeanInterceptorMetaDataBridge.java:268)
                        ... 49 more

                    • 7. Re: Info required about jboss-classloading.xml
                      Adrian Brock Master

                      With that configuration, your ejb3 won't be able to see any classes, except those in the bootstrap classloader.

                      i.e. you have no requirements (imports) and you are not using import-all=true.

                       

                      e.g. You won't be able to see anything in common/lib which includes the ejb3 api and container classes.

                       

                      Ideally, the ejb3 deployer should automatically add the ejb3 classes as <requirement/>s to all ejb3 deployments

                      that don't have import-all=true, but it doesn't currently do this. So you'll have to add them yourself.

                       

                      e.g. you could add package requirements for javax.ejb, etc.

                      but I imagine it will take a lot of work to figure out exactly what you need. :-)

                       

                      A simpler way is probably to use a module requirement:

                      vfsfile:/home/jboss/jboss-5.1.0.GA/server/all/conf/jboss-service.xml

                      which is the name of your deployment that contains all the common/lib jars (it has no nice alias).


                      vfsfile:/${jboss.server.home.dir}/conf/jboss-service.xml

                      should also work just as well?

                       

                      P.S. The NPE is a bug. You should ask the ejb3 developers to give you a meaningful error message. :-)

                      • 8. Re: Info required about jboss-classloading.xml
                        Dean Hiller Expert

                        oh, I assumed common/lib would be part of the bootstrap or be a parent or something and only jars in the deploy would need special stuff.  I am used to using knopflerfish OSGi impl where everything is just a bundle in the deploy dir(no common lib), but there is the framework classpath and everything there is on the bootstrap.

                         

                        Anyways, is there a good example of getting all of common/lib and everything needed in the classpath of my jar.  Just trying to get this simple case of exporting stuff from this jar to others who will import it once I add them too.

                         

                        thanks,

                        Dean