[Hawkular-dev] agent running as a VM javaagent - non-EAP based solution

John Mazzitelli mazz at redhat.com
Mon Mar 13 09:00:37 EDT 2017


Right, installer can be gone for standalone case.

Not in host controller case, as Heiko just said. Not because there is something wrong with the design of the javaagent, but rather there is a bug in host controller that stops our agent from being injectable into the host controller (well, you CAN inject it, but the spawned servers all crash :)

Heiko, as the fix is now currently, it will NOT fix our problem in WF 11. See my JIRA comment here:

https://issues.jboss.org/browse/WFCORE-350?focusedCommentId=13376718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13376718

There is a workaround to this that we can implement but it is a drastic measure. We can get this to work IF WE REMOVE ALL JBOSS LOGGING from the agent. That means switch to something like java util logging or slf4j and REMOVE EVERY ONE of our JBoss Logging message codes (that is remove all our MsgLogger classes and all references to their log message methods).

Note: if we can get rid of the installer for both standalone and domain, it means we can get rid of the download war that is in the Hawkular Services server.

----- Original Message -----
> On 13 Mar 2017, at 8:50, Thomas Heute wrote:
> 
> > Something that just hit me. With this we don't even need an installer
> > anymore... (we just need to include a doc page for the parameters to pass)
> 
> Yes. Not dorking with standalone.xml is a big plus.
> 
> > Simplification FTW !
> 
> So far we can't remove the installer completely as the
> javaagent does not work in domain mode due to some
> limitations of WildFly, that should be resolved in WF11.
> But at least for the OpenShift use case, this is no issue
> anyway.
> 


More information about the hawkular-dev mailing list