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/545362#545362 -------------------------------------------------------------- Moving away the idea of mixing configuration with XML scripting with ad-hoc management with ad-hoc deployment descriptors will be a big help in this arena.  No service shall be created that doesn't have (a) a management interface and (b) a concise domain.xml representation (directly or indirectly). What do I mean by an indirect domain.xml representation?  Take for example an EAR deployment.  If you take as given all the crap from my past couple posts, you'd have something like this: 1. An EAR deployment which contains WARs, EJBs, etc. 2. A domain.xml file which includes the EAR listed something like this:     <!-- ...stuff... -->     <deployment name="my-deployment.ear" sha1="ab271b2...f58289" serverGroups="foo bar baz"/> Now the deployment entry in the domain.xml file doesn't list every single EJB, thread pool, socket, web context, listener, etc. that is defined in the deployment.  The deployment has a deterministic, predictible implied mapping to services created as a result of processing the deployment descriptor.  Thus, the domain.xml remains the definitive and complete model of the domain, but it doesn't duplicate any information and it relies on the resources included therein to complete the picture. In addition, the presence of an EAR deployment in the domain *implies* that the appropriate subsystems must be made available in order to start the domain.  There is no need to explicitly list the subsystems that we need to kick off in order for the deployments to all work.  However if a subsystem needs special configuration, we certainly can and should support explicity defining those parameters in the domain. Implementation-wise this implies that the ability to *recognize* a deployment of a certain type is a separate concern from the code that actually *does* the deployment.  In addition, even the code that does the deployment might actually be split into concerns - for example we need not pull in and initialize the clustering subsystem if no components are clustered.  We can and should support lazy initialization of subsystems in this way. This way the idea of profiles is something that happens invisibly to the developer and the administrator. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/545362#545362] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]