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