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

[David M. Lloyd]

Also want to add that it is possible that a given JVM will have 
zero-or-more WildFly instances in it.  So, the phrase "find the 
container" doesn't really have meaning as there could be many (granted 
it's not usually practical to do this *today*, but I guarantee that it 
will be possible and practical in the not-too-distant future).

On 03/13/2017 05:00 PM, David M. Lloyd wrote:
> 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