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=…)
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