[jboss-as7-dev] Overriding Deployment Descriptors

[Carlo de Wolf]

Symlinking is also used to bring system installed (through rpm) 
libraries into a war or ear, not just dd-s.

Carlo

On 03/27/2012 08:48 PM, Emanuel Muckenhuber wrote:
> 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
>>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev