[jboss-as7-dev] Overriding Deployment Descriptors

[Max Rydahl Andersen]

>>> Customer requested feature is ability to externalize a file from a deployment archive and have it be an addition to the files in the archive or to override an existing file. Use cases:
>>> 
>>> 1) Production: can't crack the deployment archive for policy reasons, but need to change some config. So they add an override deployment descriptor. This AIUI is the customer requested use case.
>>> 
>>> 2) QE: override the production config to make some settings match the QE environment.
>>> 
>>> 3) Dev: same as QE, but to match the dev environment.
>> 
>> Could this feature also be used to do incremental deployments via remote management API ?
>> 
>> This is one of the reasons we avoid using the remote deployment features of AS7 since it does not allow incremental updates.
>> i.e. could we deploy a .war or .ear (exploded or zipped) and then from that point on use this "override" functionallity to replace them or will these still require full module restart to work ?
>> 
>> ( I know this i proably out of scope but just wondering if it would be a nice sideffect-feature ;)
>> 
> 
> That's out of scope for what's being done now, but it does raise an interesting point. When the original work on https://issues.jboss.org/browse/AS7-431 was done, where we said the "content" attribute for a deployment was a LIST, the idea was to use the members of that list to build up a "virtual" deployment. Those pieces of content could be anything, not just a deployment descriptor.
> 
> That approach doesn't magically mean incremental deployment would work, but it's a move in that direction.
> 
> What's being proposed now is restricting this to deployment descriptors. Basically, the overrides would be processed during deployment and then discarded. So that's not in the direction of incremental deployment.

Okey - I'm a bit puzzled on what kind of override that just affects deployment descriptors can be used for ?
Sounds like a very limiting factor and only useful in some limited cases. And what is a deployment descriptor ? I assume it just covers what AS7 considers a deployment descriptor and would not allow 3rd party framework deployment descriptors to be updated ? like seam.properties, spring or guice xml etc. ? ...and how about image resources and html content which is where I would think these overrides would be mostly interesting ?

>>> The new proposed approach (Stuart's "1)") is to have an entire new resource type, peer to deployment=foo.war, called dd-override=x. That resource would include attribute deployment=foo.war used to associate the override with a particular deployment.
>> 
>> And all this override would be via management API's, not doable with any deployment-scanner operations?
>> 
>> i.e. can I do something like:
>> 
>> cd overridestuff
>> cp * to /data/contents/xyz.war/
>> 
>> now xyz.war has an "incomplete" override of xyz.war
>> which will be "overlayed" on to deployment named xyz.war (independent on wether it comes from deployment scanner or management api)
>> 
>> or is it all just via management api's that would need to be executed on every restart/change to the data/contents folder ?
>> 
> 
> Just via management APIs. But not "executed on every restart/change to the data/contents folder". This is where the two approaches differ.
> 
> With 1), the management API call to
> 
> /dd-override=my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…)
> 
> is done once and then that override is stored in data/contents and in standalone.xml and the override will be applied every time test.ear is deployed. There is no need to do it again.

I tend to like this much better since it works independent on where the deployment comes from (management or deployment scanner)

> With 2), the override configuration is part of the deployment=test.ear config, so if that deployment is removed, so is the config.

If I understand this right then the actual deployment and override *must* be done via management API at the same time ?

For me to like this one there should be a way to do it via the deployment scanner IMO. Which I fully understand will be overkill hence why I from the outside prefer #1.

With respect to how JBoss Tools would handle these then #2 won't be supported any time soon since we simply do not want us to tie us to a deployment mechanism that does 
not allow incremental updates.
 
Option #1 I could see us have the tools "be aware off" and show the user somehow what overrides is in place by querying the management API based on the deployment name.
And I could see us add a "attach this or more selected files" to an "override" list but I'm not sure how helpful that would be compared to other missing features we got.

 /max