Requirement #2 is somewhat in conflict with some of what I've read on this thread, wherein the domain.xml configuration data is applied as an override. That means the primary and authoritative representation of the domain is the combination of wherever the overridden configuation values come from + the domain.xml configuration.
That's always going to partially be the case, because all the IOC wiring stuff is really configuration. But how far are we looking to push this concept? I'm going to give a specific example below, but I'm less interested in the specifics than the general issue of how much is meant to be coming from domain.xml.
For example, how does the profile configuration fit in? Referring to
a) the "user configuration" stuff described at http://community.jboss.org/docs/DOC-14742
b) the "server configuration" stuff described at http://community.jboss.org/docs/DOC-14743
We could, in increasing order of verbosity:
1) Ignore the whole thing; the profile name comes from -c and the configuration is outside of domain.xml
2) Declare the profile name in domain.xml (or maybe via -c) and allow some configuration overrides (e.g. a hot-deployment scan period)
3) Include a) in domain.xml
4) Include a number of a)s in domain.xml and use -c to set which one is used
5) Include both a) and b)
6) Include a bunch of a)s and all possible b)s
Options 2, 3, 4 seem reasonable.
* The same kind of thing pops up with Infinispan and JGroups configs, where AS 5 provides a number of named valid configs to choose from and the services that need a cache/channel include the name to use in their own config, with a global property to set defaults.