[jboss-dev-forums] [Management Development] - default values in domain management

[David Lloyd]

David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion

"default values in domain management"

To view the discussion, visit: http://community.jboss.org/message/546296#546296

--------------------------------------------------------------
> Alexey Loubyansky wrote:
> 
> I thought it's worth a separate thread.
> 
> There are of course very different kinds of properties. I.e. the ones that are set in deployment descriptors and those that can't be, e.g. jvm args, environment variables, etc.
You can break it down like this:
1. Properties that are part of a deployment
2. Properties that are global to the domain
3. Properties that are specific to a server group
4. Properties that are specific to a host

Items 1-3 are definitely part of the domain model either explicitly or implicitly.  If I deploy an application into a server group or server groups, then that deployment becomes part of the domain.

> Alexey Loubyansky wrote:
> At least in the beginning, domain.xml could be optional from the server instance start-up point of view. I.e. it would be possible to start a stand-alone server instance without domain.xml. Then all the services/containers would be initialized from their deployment descriptors (and possibly other config files) as it's happening now. But if domain.xml is present then the values it contains will override the corresponding values from the deployment descriptors.
My feeling on this is that deployments have to be part of the domain model if we are to retain a consistent view of configuration and deployment (i.e. to allow "undo" operations and allow servers to go offline and download changes in order when they come back online).  Since deployments are part of the domain model, you can't deploy without the domain controller.  If you get deployments, you get a domain.xml, so it's not possible to start up a server with deployments but without domain.xml.

I don't think this is incompatible with the desire that people have to (a) keep a deploy/ drop-in directory like we have to day (for development purposes) or (b) have an embeddible mode.  These could simply be a specialized, minimal implementation of the domain controller/server manager interaction.

> Alexey Loubyansky wrote:
> 
> As Brian said in the other thread this approach implies that to have correct values of a manged component in an admin tool the managed service must be initialized at a minimum.
> 
> In addition, the values for managed properties are duplicated, i.e. in the deployment descriptors and domain.xml, which is confusing. Admin tool will apply changes to domain.xml but not the deployment descriptor. domain.xml is synchronized between the server instances in the domain but deployment descriptors probably won't. Which means if the value is removed from the domain.xml the default value for the property on every server instance coming from the deployment descriptors maybe different.
I don't see any reason, given what I've said above, to *require* duplication of what's in the deployment descriptors into the domain.xml file.  It would only happen in the case where something specific needs to be overridden.

Maybe Brian's idea of having the defaults in the schema isn't such a bad one after all: as long as we have separate namespaces for each successive version of each component, the version can be used to imply the defaults in play.  We have to make sure that the implementation of the parsing layer makes it easy to support multiple namespaces (and know which is in play) in this case though.

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/546296#546296]

Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2107]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20100604/acafe270/attachment.html