[wildfly-dev] Gathering diagnostic data

[Emanuel Muckenhuber]

On 03/05/2014 10:48 PM, Brian Stansberry wrote:
> in-line...
>
> On 3/5/14, 3:34 PM, Brian Stansberry wrote:
>> On 3/4/14, 6:49 PM, James Livingston wrote:
>>> To me, the obvious place for these kind of server-specific ops in domain
>>> mode would be under /host=*/server=*/ probably under sub-model
>>
>> Doing this in a sub-resource would be very difficult as it significantly
>> complicates the issues I'll discuss below.
>>
>>> since
>>> there could be a non-trivial number of useful operations. Operations
>>> there get routed to the server to execute, but I need code run on the HC
>>> instead.
>>>
>>
>> Yes, this is a general problem; the /host=*/server=* resource actually
>> resides on the server process; on the host process at that address all
>> there is is some proxy code that proxies the request to the server.
>>
>> If you look at DomainModelControllerService.registerRunningServer() you
>> can see where it adds some extra ops to the resource registration for
>> the server address:
>>
>> // Register local operation overrides
>>           final ManagementResourceRegistration serverRegistration =
>> hostRegistration.getSubModel(PathAddress.EMPTY_ADDRESS.append(pe));
>>
>> ServerConfigResourceDefinition.registerServerLifecycleOperations(serverRegistration,
>>
>> serverInventory);
>>
>> That's ok for that single case, but we need to find a slicker mechanism
>> for doing this kind of thing. I don't want DomainModelControllerService
>> to end up full of this kind of logic.
>>
>> If you want to add in another call like that
>> ServerConfigResourceDefinition.registerServerLifecycleOperations call
>> for now to keep progressing though, that's fine. We'll just need to come
>> up with something better before we're done.
>>
>
> Looking at ConcreteResourceRegistration.registerProxyController, what
> happens is it ignores the existing child registration at server=* and
> goes ahead and registers the proxy controller because it's address is
> server=foo. So thereafter "foo" essentially masks "*" when the request
> is for "foo".
>
> If this worked more like the override model stuff instead of a complete
> mask, then operations registered for "*" would be visible.
> StoppedServerResource is what currently registers these.
>
> WDYT?
>

Yeah, something like that would make sense. At least for operations 
which should be there regardless whether the server is started or 
stopped. Where probably the gathering diagnostics data should only be 
available when the server is started?

I agree that the #registerRunningServer() should be done differently. I 
am actually surprised that this is there, i thought it's just sitting in 
a branch of mine. At least the descriptions are not exposed, so it 
should not be usable atm.

IIRC there is another problem that the actual "*" registration should be 
something like a local proxy controller, to be able to dispatch 
operations properly. I think i do have something like this sitting in 
one of my branches, i'll see if i find it again.

Emanuel