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.