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

[Jason Greene]

> On Mar 13, 2017, at 1:18 PM, John Mazzitelli <mazz at redhat.com> wrote:
> 
>> Thanks for the info. Sorry to be annoying and ask the same question over and
>> over, but what is missing from the remote management protocol that WildFly
>> already provides?
> 
> Nothing is "missing" from it per-se. As a workaround, the agent is going through this remote management protocol so it can do its thing. One feature I don't think I mentioned is the agent can monitor remote WildFly (and Jolokia) servers - I use that feature to monitor its co-located local WildFly server. Its local WildFly simply looks like a remote server and it monitors it as such. So the javaagent, even though it is running co-located in the same VM as the WildFly Server, is talking over the remote management endpoint to its WildFly server as a workaround for this inability to obtain a local client.
> 
> However:
> 
> 1) It requires the user to configure the remote management endpoint simply so it can be monitored by an agent that is already running co-located in the VM. I already envision the customer asking "Tell me again why I need to configure the remote management interface so its javaagent can talk to it?". The customer should actually be able to disable the remote endpoint entirely (perhaps to lock it down and disallow jboss-cli access?) and have this agent still work - since it really doesn't need to (or at least should not have to) talk to the remote endpoint.
> 
> 2) It requires the agent to be told what this endpoint is - if the user actually bound the remote endpoint to a non-default IP (not 127.0.0.1) or non-default port (not 9990), then they have to make sure they also configure the agent to tell it where the remote endpoint is. Potential place for user-error if they forget to do that. I suppose the agent could read standalone.xml to find out what the mgmt address/port is but a) what if its not standalone.xml? Maybe the user started with a different config? What if its not standalone but deployed in domain mode? Must look at a different config file. b) now the agent has to know how to parse standalone.xml. This can all be avoided if we just didn't have to go over the remote endpoint.
> 
> 3) Seems inefficient to have to go over a remote endpoint (even if its over a loopback device) when the agent should just be able to make intra-VM Java API calls to do this.
> 

Thanks John,

Although I am more generally asking why an agent is needed at all. Why not simply pull from the remote EAP node using a user that is setup for monitoring? That would reduce the software installation and maintenance overhead to just a configuration overhead.

-Jason