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

[Darran Lofthouse]

One thing we are adding to WildFly 11 is a common client side 
configuration including security settings.

This is used by clients such as the CLI.

If this was in place the settings it contains would be available to you.

On 15/03/17 15:16, John Mazzitelli wrote:
> Well, as I said at the outset, "using the remote management API" is how it is working today.
>
> But when deployed within the same JVM as the WildFly/EAP server, seemed it would be more efficient with less required configuration if we could just grab a local client.
>
> ----- Original Message -----
>> On 03/15/2017 08:52 AM, John Mazzitelli wrote:
>>>> 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.
>>>
>>>
>>> Mmmm... that would be bad.
>>>
>>> So, it would mean that anything that lives outside the subsystem extension
>>> cycle that uses that old MCC would somehow need to know to throw it away
>>> and obtain a new one.
>>
>> Because the line between thought experiment and reality is getting
>> blurry, I want to come back around and spell out the basic facts.
>>
>> * Yes, making an agent to control WildFly instances to avoid a
>> configuration step is theoretically possible.
>> * No, it's not a good idea for multiple reasons, and it seems likely
>> cause additional problems down the line.
>> * Unless we have another fundamental change of architecture, I don't see
>> us supporting this approach.
>> * We have other, supported ways to solve the same problem (e.g. deploy a
>> subsystem, use JMX, use the management API) and tools that can help
>> support this approach (e.g. CLI scripting).
>>
>> --
>> - DML
>> _______________________________________________
>> 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
>