[wildfly-dev] Gathering diagnostic data

[Brian Stansberry]

On 3/5/14, 5:52 PM, James Livingston wrote:
> On Wed, 2014-03-05 at 15:34 -0600, Brian Stansberry wrote:
>> 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.
>
> That makes sense, and matches what I was seeing when I was stepping
> through in a debugger yesterday. I originally thought that it proxied
> the operations not the whole sub-model.
>
>
>> 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.
>
> For now I've just stuck it on as /host=*:thread-dump(server=*), which
> works fine for developing the more interesting bits.
>
> I think these kind of per-server things logically belong under the
> server, so I'll see what gets thought up in the other branch of the
> thread.
>

Just FYI, other of these kinds of things are now under 
/host=*/server-config=*. That's the resource for the <host><server> 
config data in host.xml. These server runtime control ops don't really 
belong there; that's just where they got placed initially because we had 
no time to solve this problem.


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat