[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