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

"djordjevs" wrote:

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

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.

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

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

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.

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

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. :-)

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