[weston.price]

I am running into a problem using the JAXB deployer from the MC (2.0.0Beta3). For some reason, the deployer can't be initialized:

21:38:50,428 ERROR [AbstractKernelController] Error installing to Described: name=ManagedConnectionFactoryParserDeployer state=PreInstall
java.lang.NoClassDefFoundError: Ljavax/xml/bind/JAXBContext;
 at java.lang.Class.getDeclaredFields0(Native Method)
 at java.lang.Class.privateGetDeclaredFields(Class.java:2232)
 at java.lang.Class.getDeclaredFields(Class.java:1715)
 at org.jboss.aop.ClassContainer$1.run(ClassContainer.java:93)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.jboss.aop.ClassContainer.populateFieldTable(ClassContainer.java:89)
 at org.jboss.aop.ClassContainer.populateFieldTable(ClassContainer.java:84)
 at org.jboss.aop.ClassContainer.createFieldTable(ClassContainer.java:114)
 at org.jboss.aop.ClassContainer.initializeMetadata(ClassContainer.java:72)
 at org.jboss.aop.ClassContainer.initializeClassContainer(ClassContainer.java:59)
 at org.jboss.aop.proxy.container.ClassProxyContainer.initialise(ClassProxyContainer.java:174)
 at org.jboss.aop.proxy.container.ContainerCache.createContainer(ContainerCache.java:183)
 at org.jboss.aop.proxy.container.ContainerCache.createAndCacheContainer(ContainerCache.java:171)
 at org.jboss.aop.proxy.container.ContainerCache.initClassContainer(ContainerCache.java:159)
 at org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:92)
 at org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:72)
 at org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getDependencies(AOPDependencyBuilder.java:91)
 at org.jboss.classadapter.plugins.BasicClassAdapter.getDependencies(BasicClassAdapter.java:79)
 at org.jboss.beans.info.plugins.AbstractBeanInfo.getDependencies(AbstractBeanInfo.java:210)
 at org.jboss.kernel.plugins.dependency.DescribeAction.installActionInternal(DescribeAction.java:54)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
 at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
 at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67)
 at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
 at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:56)
 at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
 at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:170)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:592)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:603)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:476)
 at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:121)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:110)
 at org.jboss.profileservice.aop.MainDeployerAspect.process(MainDeployerAspect.java:53)
 at org.jboss.aop.advice.org.jboss.profileservice.aop.MainDeployerAspect_z_process_10062600.invoke(MainDeployerAspect_z_process_10062600.java)
 at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
 at AOPContainerProxy$0.process(AOPContainerProxy$0.java)
 at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:364)
 at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247)
 at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
 at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403)
 at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342)
 at org.jboss.Main.boot(Main.java:210)
 at org.jboss.Main$1.run(Main.java:522)
 at java.lang.Thread.run(Thread.java:613)

I had initially thought that it was the version of JAXB I had compiled against, but this does not appear to be the case as I have tried multiple versions to no avail.

I then thought it might be simply that the classes cannot be found but I tried putting them in the usual places (ie server/lib etc) also to no avail.

Also, currently the JAXB deployer only allows for a single type in the instantiation of the JAXBContext

 if (properties != null)
 context = JAXBContext.newInstance(new Class[] { getDeploymentType() }, properties);
 else
 context = JAXBContext.newInstance(getDeploymentType());

I think this should be extended to allow for passing in multiple types. I have a need for this as I use inheritance in my metadata and JAXB needs to be aware of all my types. It's either this, or force an upgrade to include to @XmlSeeAlso annotation that allows those types to be specified in the metadata itself.

Note this issue is not with the JAXB.newInstance method but rather what the JAXBDeployer knows about (ie only discovered via the getDeploymentType() method).

[starksm64]

That looks like a problem with the org.jboss.aop.ClassContainer not using the correct class loader. Create a jira issue describing the deployer descriptor in use and ask Kabir to look at it.

[adrian.brock]

No, the problem is like I said initially when I wrote this class.

The JAXB deployer helper shouldn't live in jboss-deployers.jar
because otherwise the JAXB jar will need to be in the bootstrap classpath
alongside jboss-deployers.jar
(not a problem for Java6 where it is in the JDK).

Classloading 101
import com.acme.SomeClass
means Class.forName() not thread context classloader

This class should live in a seperate JAXB integration project
that can be "hot deployed".

[weston.price]

The JAXB deployer helper shouldn't live in jboss-deployers.jar
because otherwise the JAXB jar will need to be in the bootstrap classpath
alongside jboss-deployers.jar

Fine by me. We can put it anywhere that allows me to get me work done. I don't care where it lives. Note, I actually put it alonside the jboss-deployers.jar as a test, with the same results.

I assume you knew it wasn't going to work when you checked it in, so I will similarly assume you have an idea of where to put to it to actually make it functional.

Classloading 101
import com.acme.SomeClass
means Class.forName() not thread context classloader

What is your point? Are you just trying to appear intelligent and pedantic at the same time?

This class should live in a seperate JAXB integration project
that can be "hot deployed".

Again, fine by me. I didn't see anything in this post about where you actually think it should be.

[weston.price]

What about a new structure under deployers:

jboss.jca
-->META-INF
-->jca-deployers-beans.xml
jboss-jca-deployers.jar


The JAXB deployer could live in here until we find a need to move it elsewhere.

The JAXB jars would then be moved to a more suitable location. Right now they are in client and in the deploy/jbossws.sar directory.

[adrian.brock]

The JAXB deployer helper shouldn't live in jboss-deployers.jar
because otherwise the JAXB jar will need to be in the bootstrap classpath
alongside jboss-deployers.jar

Fine by me. We can put it anywhere that allows me to get me work done. I don't care where it lives. Note, I actually put it alonside the jboss-deployers.jar as a test, with the same results.

If you want to get some work done until it is correctly refactored.

cp jaxb.jar JBOSS_HOME/lib
./run.sh -B jaxb.jar

or copy it/them to jre/lib/ext

I assume you knew it wasn't going to work when you checked it in,

That is what I said in the original post (second paragraph):
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=99846

so I will similarly assume you have an idea of where to put to it to actually make it functional.

Revenge is a dish best served cold. :-)
"I know exactly where you can put it!"

[adrian.brock]

If you want to get some work done until it is correctly refactored.

Or even simpler, just copy the class into something like:
org.jboss.resource.temp.JAXBDeployer
to avoid the classloading problem (you can't go wrong when it is in the same classloader :-).

But don't forget about it. :-)

[weston.price]

Sigh...

cp jaxb.jar JBOSS_HOME/lib
./run.sh -B jaxb.jar

or copy it/them to jre/lib/ext

I did this and put the jars in multiple places (lib/, server/lib etc). I mentioned this before.

Revenge is a dish best served cold. :-)
"I know exactly where you can put it!"

Actually kind of funny :-)

[jason.greene]

No, the problem is like I said initially when I wrote this class.

The JAXB deployer helper shouldn't live in jboss-deployers.jar
because otherwise the JAXB jar will need to be in the bootstrap classpath
alongside jboss-deployers.jar
(not a problem for Java6 where it is in the JDK).

No need, If we are going to use JAXB 2.1 on JDK6 we will need to put the api jar in endorsed (they only bundle 2.0).

-Jason

[vickyk]

While going though the simple deployment/undeployment process in the Jboss5 I observed

1) jboss.jca:name=DefaultJCAMetaDataRepository,service=JCAMetaDataRepository MBean exists and the operations like listDeploymentsForConnector() did not give the results as expected . I deployed a sample.rar and a connection factory my-ds.xml for this rar .
I keyed in "sample.ear" for the listDeploymentForConnector() and found that it did not returned any values as I was expecting the info regadring the my-ds.xml .
Before doing this I verified the deployment success by looking required MBean's at the jmx-console .

2) ConnectorMetaDataCount () and ManagedConnectionFactoryCount() are not reducing the count once the rar/-ds.xml file is undeployed .
After looking into the code I found that JCAMetaDataRepository did not have methods defined for removal .

The JCAMetaDataRepository(repository) is updated in the Parser deployer for Connector AND MCF . Actually the repository should be added in the deploy(..) of the real deployers (for Connector AND MCF).
The undeploy(....) of the real deployers should remove the entry from the repository also , this is missing right now .

PS : I understand that the RARMetaDataRepository is basically named as JCAMetaDataRepository .
http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss/resource/metadata/repository/JCAMetaDataRepository.java

[vickyk]

"vickyk" wrote:

PS : I understand that the RARMetaDataRepository is basically named as JCAMetaDataRepository .
http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss/resource/metadata/repository/JCAMetaDataRepository.java

No there is a RARMetaDataRepository , I am wrong here so this post should be related to JCAMetaDataRepository refactoring topic .
http://anonsvn.jboss.org/repos/jbossas/trunk/connector/src/main/org/jboss/resource/metadata/RARDeploymentMetaData.java

[starksm64]

"vickyk" wrote:

The JCAMetaDataRepository(repository) is updated in the Parser deployer for Connector AND MCF . Actually the repository should be added in the deploy(..) of the real deployers (for Connector AND MCF).
The undeploy(....) of the real deployers should remove the entry from the repository also , this is missing right now .

Sounds right, probably just have not sufficiently decomposed the deployer logic into the correct aspects yet.