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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev