2:03 a.m.
>> 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