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