Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion "Profiles in domain.xml" To view the discussion, visit: http://community.jboss.org/message/546047#546047 -------------------------------------------------------------- Let's get into some use cases. 1) Admin uses tool that communicates with DC to see current configuration of running domain.  That means all the default values a) have to be present in the in-memory domain model so they can be displayed and b) have to be present in the in-memory domain model on the server acting as the DC. So a) means the components which are (a) managed and (b) are in use but were not specified in the domain.xml must be provided with an SPI via which they can publish the defaults back to the domain model.  Not the end of the world. But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC. We could say the DC has the ability to query the Servers to determine defaults, but besides being a can of worms it means the admin can't just start the DC and manipulate the domain configuration. 2) Admin uses some other tool to access "the domain database" for a non-running domain and manipulate its configuration. This means the domain configuration needs to be in an accessible, persistent form; i.e.. I don't know if this is a real use case, but am throwing it out there just so we think about it. There is a nod toward it in some product requirements | Instances                will still be configurable even if they are not currently running.                Changes will become active when the instance is next started. | but it's not clear whether "Instances" means a Server (and not the DC) or whether it also means we can't require a DC. It's also unclear exactly what "configurable" means. If you can edit domain.xml in a text editor, the domain is configurable.  I'll try and get some clarity on this requirement. Re: the upgrade situation, that's a good general question. It does make clear the flaw in using the schema for defaults: if the user doesn't update their domain.xml to use new schema version, the new defaults are unavailable. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/546047#546047] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]