[jboss-as7-dev] Overriding Deployment Descriptors

[Carlo de Wolf]

On 04/05/2012 01:36 PM, Max Rydahl Andersen wrote:
>>> On Apr 5, 2012, at 12:12 PM, Carlo de Wolf wrote:
>>>
>>>> Overriding descriptors is essentially a JSR 88 functionality.
>>> I'm curious, what are the usecases in JSR 88 for this ?
>> You tell the DeploymentManager to distribute the given module with an alternate deployment plan.
> how does that affect any descriptors in the archive ?

https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/smoke/src/test/java/org/jboss/as/test/smoke/jsr88/JSR88DeploymentTestCase.java#L404

In this case we augment the archive with an extra deployment descriptor, 
but the same principal applies for overriding descriptors.

Carlo

>
> /max
>
>> Carlo
>>
>>> /max
>>>
>>>> So cracking open artifacts is not required.
>>>>
>>>> Fixing content is orthogonal to JSR 88.
>>>>
>>>> Hence a combined solution that can make sense.
>>>>
>>>> Carlo
>>>>
>>>> On 04/05/2012 11:51 AM, Max Rydahl Andersen wrote:
>>>>> I actually agree with you here on the fact that deployment descriptors is really the last thing I would like to override.
>>>>> I see much more relevance in fixing graphics or html content this way - but i'll let Brian outline what the specifics
>>>>> of the user/customer requests have been.
>>>>>
>>>>> /max
>>>>>
>>>>>> Are you sure that this truly reflects what most users want? Are you not just
>>>>>> adding a lot of complexity to cater for the whim of a small group of users?
>>>>>>  From what I can gather from this thread, the motivation for these overrides
>>>>>> are rather thin. It is based on some users having a "policy" to not
>>>>>> break-open deployment artefacts. How overriding is better or safer that
>>>>>> "breaking open" escapes me at the moment.
>>>>>>
>>>>>> Very much part of the EJB specification is the definition of roles and
>>>>>> responsibilities. As you know, it describes a definite role for composing
>>>>>> (and by implication "breaking-open" to recompose) artefacts. If your
>>>>>> configuration is too dynamic for this approach then it is a matter of
>>>>>> application design to pick this up from elsewhere (DB or properties file).
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: jboss-as7-dev-bounces at lists.jboss.org
>>>>>> [mailto:jboss-as7-dev-bounces at lists.jboss.org] On Behalf Of Max Rydahl
>>>>>> Andersen
>>>>>> Sent: 05 April 2012 10:22 AM
>>>>>> To: Carlo de Wolf
>>>>>> Cc: jboss-as7-dev at lists.jboss.org
>>>>>> Subject: Re: [jboss-as7-dev] Overriding Deployment Descriptors
>>>>>>
>>>>>>
>>>>>> On Apr 5, 2012, at 10:17 AM, Carlo de Wolf wrote:
>>>>>>
>>>>>>> On 04/04/2012 05:01 PM, Max Rydahl Andersen wrote:
>>>>>>>> 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 ?
>>>>>>>> /max
>>>>>>>>
>>>>>>> How about?
>>>>>>>
>>>>>>> standalone/deployments/xyz.war.part01/
>>>>>>> standalone/deployments/xyz.war.part02/
>>>>>>> standalone/deployments/xyz.war.part03/
>>>>>>>
>>>>>>> touch standalone/deployments/xyz.war.dodeploy
>>>>>> I like that but I thought these were ment to be put in a separate location
>>>>>> than /deployments ? (if not then +1)
>>>>>>
>>>>>> /max
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>