David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion "domain.xml work" To view the discussion, visit: http://community.jboss.org/message/545360#545360 -------------------------------------------------------------- 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 http://community.jboss.org/wiki/DomainRequirements -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/545360#545360] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]