David Lloyd wrote:
Brian Stansberry wrote:
The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.
I get where you're coming from. I'd just be concerned though if it got to a point where it is impossible to start up a server without a large and complex domain.xml file. I don't like the idea of merging XML documents though. I don't think the defaults would be coming from everyplace, just from components which are (a) managed and (b) are in use but were not specified in the domain.xml.
Another scenario this could be relevant is where a component is upgraded, causing more features to become available. The component might want to update its domain configuration with the new default values for the new features. Patching a secondary XML file at upgrade time seems much messier than just using the defaults from a management perspective.
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.