[wildfly-dev] a way to obtain local ModelController within javaagent?

Jason Greene jason.greene at redhat.com
Mon Mar 13 11:29:25 EDT 2017


Hi John,

Before moving with non-traditional access like this I think we need to make sure the overall strategy behind what you are building is something we can support over multiple releases. Of course, a lot of that depends on your compatibility expectations.

> On Mar 13, 2017, at 10:08 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to get a ModelController to create the client. That method is deprecated and I plan to remove it in the next release (WildFly Core 4 / WildFly 12).
> 
> Use ServiceName.parse("org.wildfly.managment.model-controller-client-factory”) to get a ModelControllerClientFactory and use it to create a client, calling createSuperUserClient.
> 
> Note that if you want that client to work properly in a SecurityManager enabled environment your code will need to have org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL PERFORM_IN_VM_CALL. The security guys added in that requirement for WF Core 3. Note that applies even if you use the deprecated ModelController.createClient method. 
> 
>> On Mar 12, 2017, at 8:32 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>> 
>> You can call org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do this, however it is trickey from a JavaAgent (as the module will not be available from the agent's class loader). 
>> 
>> Unfortunately there is no getting around this, as none of the API classes you need will be available in the module. As I see it you have a few different options:
>> 
>> 1) Use reflection to get hold of this class, and then use reflection to make the calls
>> 2) Create a class that does this directly, and then make sure it is loaded from the server module (which has access to the classes you need).
>> 
>> There may be some other options, but that is all I can think of of the top of my head.
>> 
>> If you want more info on how to implement either of these approaches feel free to ask me on hipchat.
>> 
>> Stuart
>> 
>> On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli <mazz at redhat.com> wrote:
>> OK, here's another one where I need some secret magical sauce - hoping someone knows of a technique I can use.
>> 
>> Suppose I have a javaagent installed in a WildFly server (using the standard -javaagent VM argument).
>> 
>> The javaagent would like to talk to the WildFly Server it is co-located with. Since it is in the same VM, the javaagent wants to avoid it looking like a remote call.
>> 
>> But I know of no way to obtain a local ModelController instance to build a client short of injecting some service or subsystem into WildFly itself (something I would like to avoid).
>> 
>> If the javaagent were instead a subsystem extension, it could do something like this:
>> 
>>   InjectedValue<ModelController> mcValue = new InjectedValue<>();
>>   ...
>>   ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue);
>>   ...
>>   WHAT_I_WANT = mcValue.getValue().createClient(...)
>> 
>> But obviously, that's no good for something running outside of the WildFly container (albeit in the same JVM).
>> 
>> Any hope at all? I was thinking some trickery on the order of what ByteMan does in order to figure out a way to obtain a local ModelController? But that's a last ditch effort :) Hoping there is something that uses a little less witchcraft.
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
> 
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat




More information about the wildfly-dev mailing list