[sending this to the open source project community mailing lists for RHQ and Wildfly] This is to kick off a discussion regarding embedding a RHQ agent [3] into an WildFly instance (which will also be applicable to downstream projects JON and EAP respectively - but I'll continue to use RHQ and WildFly since the code will almost certainly go in those upstream projects). The thought is to embed a RHQ Agent in a running WildFly instance, specifically a Host Controller. In the standalone RHQ use-case, a single RHQ Agent process runs on a box and manages all the things on that box. Since there is one Host Controller on a box, it seems to make sense to embed a RHQ Agent there. This is something we can discuss (do we embed in Process Controller instead? The initial thought was no, probably not a good idea). This would allow a person to "flip a switch" to enable RHQ management of their WildFly infrastructure running on that box without having to separately install a RHQ agent on their own. Now, by following the "Extending WildFly 8" example subsystem [1] I already have an initial implementation of an embedded agent extension subsystem [2] and it is able to run in a standalone WildFly 6 instance. It will be turned off by default, so its footprint is minimal by default (just a few extension classes need to be loaded - like the definitions, the add/remove step handlers, etc). But when you do have it enabled, a fullblown RHQ Agent will be started in the WildFly instance. Today, I have this working - it loads all the necessary plugin jars and native libraries to manage platform services and WildFly resources. The RHQ team might even consider this as its own embedded agent for use within the RHQ Server itself (since a RHQ Server is itself running in a standalone WildFly 6 instance, this thus allows a RHQ Server to manage itself with its own embedded RHQ Agent). It was my mistaken impression (which Brian mentioned to me recently) that Host Controllers have extensible subsystems like standalone instances do. I looked in domain.xml, saw <extension> and <subsystem> tags and just assumed it worked like standalone, but alas, it does not. So, one question would be - how easy would it be to have extension subsystems installed and run in a Host controller like we do in standalone instances? Otherwise, what has to be done to implement a new subsystem in a Host controller, if it is not done like the "Extending WildFly 8" example. Another question (probably the first question) to answer is - do we even need to embed an agent like this? Or, is simply packaging a RHQ Agent with WildFly Host Controllers all that is needed for a better user-experience than what people have today (which is to separately install RHQ agents after they install WildFly and domain/host controllers?) Can an embedded agent provide better functionality than a separate process/instance of the RHQ agent (even if it is distributed within an WildFly distro?). There are other issues, obviously, to consider: * If a Host Controller gets shutdown, that means the RHQ Agent goes down with it (and thus manageability of that box goes away). * Do we allow the RHQ Agent running in a Host Controller to manage EVERYTHING on this box (like a standalone agent would) or do we just want that agent to manage only the WildFly on that box? ** If its the latter (manage only WildFly), how do we want to be able to manage everything else on that box (or do we even want to do that?). * What about testing requirements (what kind of tests are required to get an embedded agent into the WildFly buld?) * How do we do packaging of an embedded agent? * etc. etc. etc. yadda. yadda. yadda. OK, so that's the kickoff email. I'll let others take it from here and move this conversation in the directions that people want it to go. --John Mazz [1] https://docs.jboss.org/author/display/WFLY8/Example+subsystem [2] source can be found here: https://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/ser... [3] see http://www.jboss.org/rhq