[wildfly-dev] a way to obtain local ModelController within javaagent?

John Mazzitelli mazz at redhat.com
Wed Mar 15 11:16:26 EDT 2017


Well, as I said at the outset, "using the remote management API" is how it is working today.

But when deployed within the same JVM as the WildFly/EAP server, seemed it would be more efficient with less required configuration if we could just grab a local client.

----- Original Message -----
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



More information about the wildfly-dev mailing list