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/smo...
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(a)lists.jboss.org
>>>>> [mailto:jboss-as7-dev-bounces@lists.jboss.org] On Behalf Of Max
Rydahl
>>>>> Andersen
>>>>> Sent: 05 April 2012 10:22 AM
>>>>> To: Carlo de Wolf
>>>>> Cc: jboss-as7-dev(a)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(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>