David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com
] replied to the
To view the discussion, visit: http://community.jboss.org/message/545360#545360
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:
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
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
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"
 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
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
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.
Reply to this message by going to Community
Start a new discussion in Management Development at Community