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&...]