Brian Stansberry [
http://community.jboss.org/people/bstansberry%40jboss.com] replied to
the discussion
"default values in domain management"
To view the discussion, visit:
http://community.jboss.org/message/546508#546508
--------------------------------------------------------------
David Lloyd wrote:
> Alexey Loubyansky wrote:
>
> 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.
Agreed. Going through
https://community.jboss.org/docs/DOC-15303 the lifecycle use cases
what seems to be falling out is a two step process where step 1) is registering with a
domain and getting the local environment consistent with the domain, then step 2) starting
a Server based on the domain.xml. A "stand-alone server" use case or an embedded
one would mostly differ from the more complete one in skipping step 1). (Embedded would
presumably also at least partly use an API to establish the domain model rather than
getting everything from a domain.xml.)
Interesting question on how to do deployment operations and make config changes on a
"stand-alone" server. If the stand-alone server is running the
DomainControllerSubprofile, then it exposes the full management capability of a larger
domain and can be managed the same way. If it doesn't run the
DomainControllerSubprofile, then we need to establish what post-startup management
capability it will expose.
First, my opinion on a requirement: the "standalone server" and embedded use
cases are meant for developers, not for production systems. Setting up a production
system consisting of a bunch of stand-alone servers, each running the
DomainControllerSubprofile could work but is not the recommended architecture. Setting up
a production system consisting of a bunch of stand-alone servers that don't run the
DomainControllerSubprofile is not a supported architecture.
Put another way, the full stable supported management API we are developing is exposed by
a DomainController, so if you want the full capabilities you need the
DomainControllerSubprofile. But what does API does the non-DC stand-alone server expose?
I think the answer to this will largely fall out of working through the embedded use
cases, plus working out the interaction between a separate-process DC and a Server. For
sure a stand-alone server needs an deployment API, otherwise it's useless in an IDE.
One thing I think there is consensus on: hot deployment is limited to a deploy/ dir that
only contains end user deployments, no core services. So reconfiguring a core service by
changing some -beans.xml file and having HDScanner pick it up is not a supported
configuration mechanism.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/546508#546508]
Start a new discussion in Management Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]