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/546496#546496
--------------------------------------------------------------
Alexey Loubyansky wrote:
Ok, so far we agree that defaults come from the deployment descriptors. At least it would
be the next (perhaps not the last) source for initialization values if they are missing
from the domain.xml.
Yeah, I think it's hard to say anything more specific
without use case examples. Some things might not appear in a deployment descriptor at all
though, like the JBossWeb server configuration for example, because they apply to the
server as a whole, not a specific deployment.
Alexey Loubyansky wrote:
By property/value duplication I didn't mean it as a requirement for all the
properties. But it will be the case for those that are overriden in domain.xml. It's
not so much a value duplication but the property config duplication which won't be in
sync (between the domain.xml and the deployment descriptors) which is a bit confusing.
What do you mean by "in sync" in this case? One would only override a
configuration property if there was a deployment to override. I imagine that any
overriding properties in the domain.xml file that pertain to a specific deployment will be
children of an element which defines that deployment, so if there's no such element,
there's no such deployment, and such an element can't exist without the deployment
being present.
Alexey Loubyansky wrote:
Ok, so I think I understand it better now. Again, correct me if I am wrong:- to start a
domain (member of a domain), I'll use a separate tool/script (not the usual
run.sh/ran.bat) that will start things according to the domain.xml (that will happen in
collaboration with the domain controller or actually the tool/script will just delegate
the tasks to the domain controller);
- further dynamic (hot) deployment operations will also be performed using a tool/script
and through the domain controller;
- config changes of any kind (including managed components) will be performed also using
a tool/script and through the domain controller.
So, actually, in the domain-running mode all the operations including start-up/shutdown
and any config changes will be performed using a tool/script, not manually, i.e. not by
manually changing deployment descriptors at runtime, manually copying/removing deployments
from the deploy dir, etc.
At the same time, there will still be the usual run.sh/run.bat that will start server
instances as usually (passing by the domain.xml), they won't join the domain, i.e.
will be running stand-alone and deployment operations and config changes will be performed
traditionally manually.
Yes and no. We can still have a deploy directory. But *if*
we do, the scanner for that directory would take deployments and feed them through the DC,
so the domain model info would be automatically updated at the same time.
We can still have run.sh; it just starts the server manager which starts all the server
instances according to domain.xml.
I don't forsee any mode of operation that does not involve domain.xml. Even an
embedded server should have something performing the role of DC and SM even if it's
all in the same process space. This way there's only one API for deployment and
configuration.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/546496#546496]
Start a new discussion in Management Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]