On 03/15/2017 08:52 AM, John Mazzitelli wrote:
> I was thinking about this yesterday and realized that an MCC
accessed this
> way will be broken following a reload. An extension that obtains an internal
> client doesn’t have this issue as the entire subsystem goes away and is
> started again as part of the reload. But something that lives outside that
> cycle is going to need a different integration.
Mmmm... that would be bad.
So, it would mean that anything that lives outside the subsystem extension cycle that
uses that old MCC would somehow need to know to throw it away and obtain a new one.
Because the line between thought experiment and reality is getting
blurry, I want to come back around and spell out the basic facts.
* Yes, making an agent to control WildFly instances to avoid a
configuration step is theoretically possible.
* No, it's not a good idea for multiple reasons, and it seems likely
cause additional problems down the line.
* Unless we have another fundamental change of architecture, I don't see
us supporting this approach.
* We have other, supported ways to solve the same problem (e.g. deploy a
subsystem, use JMX, use the management API) and tools that can help
support this approach (e.g. CLI scripting).
--
- DML