This is something I've been thinking about for a while.
Problems:
1. We need the ability to allow "overlay" content on a deployment, so
that certain settings can be overridden and patches can be applied, and
so forth. In other words, a deployment may consist of more than one JAR.
2. A standalone server may have content rooted outside of the
repository (i.e. on the filesystem). Especially for exploded
deployments, we need to be able to detect and respond to content changes
immediately with a minimum of fuss.
3. We need the ability for administrative overrides to be placed on
deployments. In other words, it should be possible to override certain
settings via the management API without changing the deployment content.
Solution:
All of these problems can be solved by changing the structure of a
deployment declaration in the domain model. I'll use XML notation to
illustrate.
Before:
<deployment
name="mydeployment.ear"
runtime-name="mydeployment.ear"
sha1="012345...."
start="true"/>
After (complex case):
<deployment name="mydeployment.ear" start="true">
<!-- runtime-name should default to name -->
<!-- this is where we specify content -->
<repository-content sha1="012345...."/>
<repository-content sha1="123456...."/>
<filesystem-content path="${jboss.deploy.dir}/mypatch.jar"/>
<configurations>
<configuration xmlns="urn:jboss:domain:web:1.0">
<!-- this is completely contrived -->
<override-virtual-host name="my-production-domain.com"/>
</configuration>
</configurations>
</deployment>
After (simple case):
<deployment name="mydeployment.ear" start="true">
<repository-content sha1="012345..."/>
</deployment>
Let me know what you guys think. In particular, unaddressed items
include: pluggable content providers, and XML schema issues, and
non-stupid element names; I'm just floating the general idea here
because something like this has been an assumption I've been carrying
around so if someone is going to shoot it down, now is better than after
I've invested heavily in it.
--
- DML