Scott Stark wrote:
Some initial work on a collection of xml schema files to codify the notion of the domain metadata model have been uploaded here:
http://community.jboss.org/wiki/JBossASDomainSchema
I followed our http://community.jboss.org/wiki/DomainManagementModelDesign for the structure and incorporated some of our existing schemas as a starting point to see how well these would pull together since the domain metadata ultimately needs to map onto this view where it exists.
In general, the imported schemas expose too much detail, and there need to be better cross cutting configuration notions for common services such as security, threads, pools, remoting, logging, etc. We need alternate domain admin views similar to what I did with the profiles where it is very much simplified and only focused on the requirements the admin is looking for. There is no notion of deployments at this level.
Of course there is a ton of configuration data to add for the various containers as well.
I'm handing this off to Alexey, so good luck!
Getting more specific, this raises some questions.
The defined requirements around the domain.xml file are all very vague/general, for example "represents the primary and authoritative representation of the domain" [1] or "focused on the requirements the admin is looking for". I think it's time that we start getting specific about what the domain.xml needs to be, not just in terms of example schemas or in terms of broad strokes but in detail.
If the domain.xml does, indeed, contain the authoritative representation of the domain, then it does indeed need to contain, directly or indirectly, definitions of all serivces available up to and including the list of active deployments. For example, as defined in the existing requirements, a deployment can be associated with one or more server groups, which are defined as part of the domain. If the domain doesn't map deployments to server groups, what will? In addition, adding deployments can very well imply other changes to domain.xml that are necessarily made at the same time. Everything I see in the requirements says to me that the current deployment listing must be a part of the domain model.
So if you take that as a given, then the question isn't about too much detail in the domain model (which ultimately has to contain every detail, regardless of its relative relevance), it's more about too much detail in the domain.xml file itself, and how can we hide some of the less-likely-to-be-useful detail without crippling the administrators or us poor implementors.
For example, today the thread pool configuration is highly granular. Many of the things can have reasonable defaults; for example rather than specifying the thread factory for every thread pool, and the thread group for every thread factory, etc. we can have a default thread factory and group, or auto-create one with reasonable parameters which can be overridden in the case where the admin needs finer-grained control. Many of the quirks of jboss-threads in particular are due to JBossXB and MC, and just following the path of least resistance.
It might be helpful to break it down into categories, and for each category, formalize how it should be represented in the management view versus the domain.xml file.
[1] http://community.jboss.org/wiki/DomainRequirements