11 p.m.
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