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

[David M. Lloyd]

On 03/13/2017 01:41 PM, John Mazzitelli wrote:
>> To me it seems like, when running in WildFly you always want it to be a
>> subsystem, and when running not in WildFly, you always want it to be an
>> agent.
>>
>> In other words, you're describing two pieces of software (with some
>> shared/common code) that do two different things in two different
>> scenarios, and you're trying to make it all one.
>>
>> If my understanding is correct, I don't think this is really going to
>> save any work compared to supporting two different things with common
>> code.  If anything, the combinatory approach going to cause extra work
>> due to trying to make a square-and-round peg try to fit in a
>> square-or-round hole.
>
> Well, actually the "have two agents" is going to be more complicated than this "all-in-one agent" - certainly more complicated from a support/maintenance point of view.
>
> I have the all-in-one "java agent" working now (aside from those two issues I mentioned). If I could just get a local ModelController, the same piece of software can monitor:
>
> 1) Local WildFly/EAP servers (standalone and host controller)
> 2) Local JMX servers
> 3) Remote WildFly/EAP servers (standalone and host controller)
> 4) Remote JMX Servers
>
> Having this all-in-one javaagent (versus having two separate agents) means the amount of work this would save is quite a lot. For example:
>
> a) We would no longer have to support and maintain the subsystem extension code itself (not to mention all the ancillary code like the feature pack mvn module).
>
> b) We no longer would have to support/maintain/document two different configuration files (one for the <subsystem> in standalone.xml/host.xml and one for the javaagent yaml file)
>
> c) We no longer have to support the agent installer. This agent installer is a piece of additional software that is needed because people complained about having to manually copy the binaries in the add-ons dir and to configure the <subsystem> XML to get the agent installed (along with its related stuff like any required <security-realms> and <socket bindings> that the agent needs). We ended up writing an installer that can install the add-ons binaries and inject the necessary XML in standalone/host xml so the user doesn't have to. But upgrading such an installment is still a problem - that installer doesn't support upgrading the XML.
>
> Does WildFly today have a subsystem extension installer/upgrader that allows users to install add-ons in their own WildFly servers so a user doesn't have to configure standalone.xml/host.xml with the add-on's required <subsystem> XML?

Generally speaking, no, not yet, though you can use the CLI to do and 
script various things.

> Does it modify/upgrade that XML in standalone.xml/host.xml if an older version of the add-on already exists?

This is automatically done at server start in most if not all cases, not 
by any tool but by the management model itself.  The XML isn't the 
model; it's just a serialization of it.  Interaction with the 
configuration often (usually?) is done via CLI and the console, rather 
than by manipulating the XML itself.

> If such a tool exists, that would help a lot. Right now, it is a pain to have to write and maintain the agent's own installer. :) If WildFly has such a tool available already, then this issue with having to maintain/support an installer goes away for me. I did not think such a thing existed, at least not at the time when we wrote this agent installer.

If you're manipulating XML directly then it's possible that the CLI can 
do most of what your installer is doing in a more resilient manner, and 
possibly a simpler manner as well.  Have you looked into it?

-- 
- DML