I was thinking about this yesterday and realized that an MCC accessed this way will be
broken following a reload. An extension that obtains an internal client doesn’t have this
issue as the entire subsystem goes away and is started again as part of the reload. But
something that lives outside that cycle is going to need a different integration.
On Mar 13, 2017, at 10:08 AM, Brian Stansberry
<brian.stansberry(a)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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat