Scoped deployments in AS 5.x

[beve]

In ESB 4.x you can specify that a deployment be scoped by configuring this in deployment.xml:

<jbossesb-deployment>
 <depends>jboss.esb:test=server</depends>
 <depends>jboss.esb.qa.junit.destination:service=Queue,name=esb_gateway_channel_versioned</depends>
 <depends>jboss.esb.qa.junit.destination:service=Queue,name=esb_channel_versioned</depends>
 <loader-repository>
 org.jboss.soa.esb:loader=simple-scoped
 <loader-repository-config>
 java2ParentDelegaton=false
 </loader-repository-config>
 </loader-repository>
</jbossesb-deployment>

In AS 5.x something similar can be done by adding a META-INF/jboss-classloading.xml file to a deployment.
I'm guessing that our deployers should act upon a loader-repository element in deployment.xml and take care of this when a .esb archive is deployed into AS 5, and not force users to declare such a file?

/Daniel

[kconner]

The configuration in deployment.xml just proxies through to the app server code, we do not do anything with it.

The main reason for doing this within the AS 4 deployer was probably a consequence of the app server's restriction in only allowing a single deployer per deployment, so each deployer was responsible for handling this.

This is no longer necessary in AS 5 so we should follow the standard mechanism, using the jboss-classloader.xml.

Kev

[beve]

This is no longer necessary in AS 5 so we should follow the standard mechanism, using the jboss-classloader.xml.

Glad I asked :) jboss-classloader.xml it is then.

Thanks

[beve]

So for a ESB 4.x scoped deployment users will be required to create a META-INF/jboss-classloading.xml:

<classloading xmlns="urn:jboss:classloading:1.0" domain="simple-scoped" parent-first="false" />

which will "replace" the 'loader-repository' element in META-INF/deployment.xml:

<jbossesb-deployment>
 <loader-repository>
 org.jboss.soa.esb:loader=simple-scoped
 <loader-repository-config>
 java2ParentDelegaton=false
 </loader-repository-config>
 </loader-repository>
</jbossesb-deployment>

The 'loader-repository' element can be left but will be ignored by the AS 5 esb deployers.

/Daniel

[emuckenhuber]

Just in case - if you are interested in supporting the legacy loader-repository config in your deployment descriptors, you could 'translate' that into the AS5 classloading metadata.

So you would need to create your own ClassLoaderDeployer in POST_PARSE, which has your deployment meta data as input and as ouput the ClassLoadingMetaData.
You could look at this:

https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java
and
https://svn.jboss.org/repos/jbossas/branches/Branch_5_x/system-jmx/src/main/org/jboss/system/deployers/LoaderRepositoryConfigHelper.java

The way this is written it first checks if there is already a classloading meta data (a jboss-classloading.xml) - if not you could create it based on the loader-repository from the esb deployment descriptor.

[beve]

Just in case - if you are interested in supporting the legacy loader-repository config in your deployment descriptors, you could 'translate' that into the AS5 classloading metadata.

Thanks for the details on how to do this. This was what I was thinking we could do when we parse our deployment.xml. We could then 'translate' that into classloading metadata but was not sure about exactly how this would be done but you provided that :)

Kev, what do you think?

/Daniel

[kconner]

My preference would be to stick with the AS mechanism rather than to continue the deployment specific configuration, at least until we have a good reason why we need to intervene. This was a necessary evil within AS 4 but should no longer be required using microcontainer. Moving from AS 4 to AS 5 will be a big enough change in any case, differences will arise.

We do have plenty of time to revisit this should it become necessary but the main advantage to us of not supporting it would be consistency with other deployments within the microcontainer (configuration and behaviour), and of course it would be someone else's code :)

Use the AS mechanisms as much as possible for now and we will see where we end up. If we do need to introduce ESB specific mechanisms then we can look into it at a later stage.

Kev

[beve]

Use the AS mechanisms as much as possible for now and we will see where we end up. If we do need to introduce ESB specific mechanisms then we can look into it at a later stage.

Yeah, that sounds like a plan. And we have Emanuels links there if we need them later.

/Daniel

[beve]

I've added a note about this on the wiki:
http://www.jboss.org/community/wiki/ESB4xdeploymentsonJBossAS5