[jboss-as7-dev] Overriding Deployment Descriptors

[Carlo de Wolf]

Overriding descriptors is essentially a JSR 88 functionality. 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
>>