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