On Mar 13, 2017, at 5:00 PM, 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
>> 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
> 1) Local WildFly/EAP servers (standalone and host controller)
Why do you need a ModelControllerClient to look at metrics? I believe metrics should be
available over JMX. In another thread you asked about DMR->JMX and mentioned
deployments. So if you want to do complex stuff like deployments, or really any writes,
using a ModelControllerClient makes sense. But the "WHAT THE AGENT DOES:” section
earlier in this thread just talks about metrics.
> 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
> 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).
This security and socket related config that used to be part of the server config is now
in a yaml file the the javaagent is configured to access?
> 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.
This depends on what the upgrade is. The server will automatically move a subsystem config
to the latest schema version, but if the new code has some new functionality we don’t
automatically inject that into the config. Your parser for the old schema version could do
that in theory, but generally that’s a bad practice.
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
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?
The EAP installer itself uses the CLI in this way.
wildfly-dev mailing list
Manager, Senior Principal Software Engineer
JBoss by Red Hat