The deployer creates the DeploymentInfo (and classloader)
like the old rar deployer,
Except now the rar metadata is from ra.xml and the xxx-rar.xml overrides.
There is just an additional source of metadata from the xxx-ra.xml
it would also be that one that is watched for hotdeployment purposes.
I'm not saying you should do it this way. It is one possible way
to achieve the externalization of the overrides.
Another would be an even more generic deployer that
has something like:
<deploy> <file>xxx.Xar</file> <alt-dd-file>/some/location</alt-dd-file> or <alt-dd> <!--inline stuff--> </alt-dd> </deploy>
The existence of the rar in/not in the deploy directory is a separate issue that relates to how the hot deployment service has to behave in the presence of a profile service, as that dictates what deployments are part of a server configuration. Certainly a rar can have jboss specific deployment descriptors. A deployer will ultimately have to support an external metadata configuration based on the management view it exposes to effectively integrate with the profile service though, because the profile service is not going to be writing out deployer specific descriptors. It will have an object representation it stores however, and this will be passed in as additional metadata at deployment time.
Damn, I knew I forgot something.
This has been done in HEAD. In the interim, I punted and wen the simple ra-xml inside the RAR route until I can get a better handle on the profile service. Right now the XML parsing is done via XB, but I plan, at some point to switch it over to JAXB if it makes sense.
I know, I know...lazy ass fix for this problem rather than doing it the right way. But it solves the 'immeadiate' need for overriding those properties.