[jboss-as7-dev] Overriding Deployment Descriptors

[Emanuel Muckenhuber]

The part i am trying to figure out is that we basically would have 2 
things doing the same. Another issue people are complaining about is 
that we don't support symlinks in .war deployments. One of the easiest 
ways to solve this would be to just mount a local file system path. 
Where i am not sure if moving this to the dd-overrides makes more sense. 
Hopefully i do remember correctly that we support VFS in our web 
integration :)

I think the dd-override sounds like less work in the beginning, but if 
you include invalidation of overrides i am not sure if that is also true 
for all the tooling. The deployment-scanner seems to be an edge case in 
general, so perhaps we it can just adapt (be smarter) once we have some 
other workflows.

On 03/27/2012 08:04 PM, Brian Stansberry wrote:
> It's not immediately critical. But a little voice inside my ear tells me
> we'll be *strongly* pressured to support it at some point. People love
> the deployment scanner. And I think once people get used to being able
> to have override descriptors they will love that as well.
>
> Override descriptors are very nice for keeping a base deployment but
> adapting it for different environments. I'd thought of it as more of a
> production thing (a workaround to a corporate policy that says a jar
> can't be cracked open and change) but David convinced me it's more of a
> developer or staging thing (override the production settings with
> dev-workstation-specific settings). And once you are talking developers,
> you are also talking deployment scanner.
>
> A big question I'd like to see talked through on this thread is how best
> to do tooling around this (including CLI and web console.) What's
> easiest for the user, in common workflows?
>
> In option 1, the dd-override is a separate resource from the deployment.
> That means it can be independently controlled. Good and bad there. Good,
> it can be added once and then left alone while the war, whatever is
> tweaked and redeployed many times. Bad, it's a separate thing.
>
> Conversely, with 2, the content items are part of a list attribute of
> the deployment resource. The good and bad points are the opposite of 1.
>
> On 3/27/12 12:47 PM, Emanuel Muckenhuber wrote:
>>
>> Hmm, so we really have to support the deployment-scanner use case? I
>> mean beside some API/address differences - the (not implemented)
>> deployment content thing is basically doing the same. Just wondering if
>> i missed something obvious?
>>
>>
>> On 03/27/2012 03:55 PM, Brian Stansberry wrote:
>>> On 3/27/12 12:34 AM, Stuart Douglas wrote:
>>>> We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought.
>>>>
>>>> 1) Allow the user to specify alternate deployment descriptors as part of the deployment process
>>>>
>>>> At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it.
>>>>
>>>> 2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment.
>>>>
>>>> e.g.   to add the descriptor you would do something like:
>>>>
>>>> /dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…)
>>>>
>>>> or for domain mode
>>>>
>>>> /server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…)
>>>>
>>>
>>> For domain mode, this should be basically a parallel to the existing
>>> deployment=* handling:
>>>
>>> a) The override is a top level resource, adding an item to the
>>> "pallette" that is usable in any server-group:
>>>
>>> /dd-override=my-deployment-descriptor:add(deployment="test.ear",
>>> file="test.jar/META-INF/ejb-jar.xml", content=…)
>>>
>>> b) The server-group part is just a mapping that says "use this from the
>>> pallette:
>>>
>>> /server-group=foo/dd-override=my-deployment-descriptor:add
>>>
>>> Actually, this last bit is probably unnecessary, since the HC can figure
>>> out what dd-overrides are required from the deployment="test.ear"
>>> attribute on the dd-override=my-deployment-descriptor resource.
>>>
>>>> Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml.
>>>>
>>>> 2) is the approach that I prefer, as I think it gives the most flexibility.
>>>>
>>>> What does everyone think?
>>>>
>>>> Stuart
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>