7:41 p.m.
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? Does it
modify/upgrade that XML in standalone.xml/host.xml if an older version of the add-on
already exists? 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.