I have a WAR that is configured to use a scoped classloader under JBoss. This all works fine and dandy. The configuration for it in jboss-web.xml looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 4.2//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_4_2.dtd">
<jboss-web>
<class-loading>
<loader-repository>
com.mycompany:loader='com.mycompany.repository'
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</class-loading>
</jboss-web>
Now, a client wants to deploy two copies of our WAR file under the same JBoss instance. They are configured to use the same classloader repository, which causes problems.
If I manually change jboss-web.xml inside one copy of the WAR file to specify a different repository, e.g by changing the relevant line to:
com.mycompany:loader='com.mycompany.repository2'
...both copies of the WAR deploy without trouble.
However, hacking the internals of the WAR file isn't a fantastic solution for a customer.
If I could incorporate, say, the context root into the name of the repository (or some other property that is guaranteed to be different between two the two deployments), this could be accomplished automatically.
Is it possible to use properties within jboss-web.xml?, letting me do something like:
com.mycompany:loader='com.mycompany.repository-${jboss.context-root}'
(Note: I made up that property name.)
Stepping back a bit, is there a better way to accomplish what I'm trying to accomplish?
The normal J2EE way of achieving what you want is to separate code from deployment. This means that putting jboss-web.xml
into the WAR is the mistake here.
This deployment-specific configuration file should be used during deployment. I don't really know the jboss deployment process, but for Oracle IAS it is the following:
web.xml
), but not the values for the entriesorion-web.xml
for Oracle, jboss-web.xml
for jBoss ) containing the mapped runtime values for the roles, datasources, env-entries etc. is passed to the container (This is done in a container specific way, Oracle takes a deployment plan file given via cmdline arg or via upload in Browser form, i.e. you upload EAR and deployment plan, deployment plan contains all vendor-specific deployment descriptors)The JSR 88 defines the deployment plan concept and also defines a deployment plan facility . So this should be your starting point fo looking int jboss documentation.
As said before, this is the standard J2EE way of separating deploy-time value mappings from your code WAR/EAR. In your particular case you would end up with one EAR and two different deployment plans.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With