On 3/4/14, 6:49 PM, James Livingston wrote:
On Wed, 2014-02-26 at 06:41 -0600, Brian Stansberry wrote:
> You either need to provide 2 ops, or the details with no fallback, or
> just the unstructured text. It can't be a single op that provides well
> structured data except if something goes wrong in which case it provides
> unstructured text. The metadata for an op describes the structure of the
> return data, and that description can't be ambiguous.
> I think starting with a just-text op is best and then let your users
> help drive your roadmap.
Thanks, I'll do that and see what everyone wants to use it for.
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.
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
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 =
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
for now to keep progressing though, that's fine. We'll just need to come
up with something better before we're done.
I've seen the HOST_CONTROLLER_ONLY flag which sounds like what I
but that doesn't affect /host/server ops. Am I mis-understanding the
flag and that's not what it's for, or should it work?
That's not what it's for. :) It's for preventing 2-step behavior when it
would otherwise occur, but in this case 2-step behavior isn't desired.
PrepareStepHandler uses isServerOperation() to direct operations
server to the instance without regard for HOST_CONTROLLER_ONLY, and
OperationRouting.determineRouting() only checks the flag if it's not in
The routing is correct -- the call should execute direct and not go into
the 2 phase logic used for stuff that applies locally and then gets
rolled out to servers. This needs to be solved via some more
sophisticated behavior in the HC process at the /host=*/server=* address.
Senior Principal Software Engineer
JBoss by Red Hat