[jboss-as7-dev] validate-address warning

Brian Stansberry brian.stansberry at redhat.com
Mon Jul 18 12:39:55 EDT 2011


On 7/18/11 10:45 AM, Alexey Loubyansky wrote:
> On 07/18/2011 04:32 PM, Brian Stansberry wrote:
>> On 7/18/11 6:40 AM, Alexey Loubyansky wrote:
>>> I just noticed that if validate-address has a negative result there is a
>>> WARN in the server's log. Do we really need that?
>>
>> No.
>>
>>> I just realized that CLI may cause quite a lot of those.
>>>
>>> [Host Controller] 13:34:50,256 WARN  [org.jboss.as.controller]
>>> (pool-3-thread-6) Operation ("validate-address") failed - address:
>>> ([("subsystem" =>    "messaging")])
>>>
>>
>> I wonder why it's happening? That message gets logged if the step
>> handler throws OperationFailedException, and this handler doesn't.
>>
>> The intent is a handler throws an OFE if there is an error in the user
>> request, and we WARN log it instead of ERROR because it's not an error
>> condition on the server. This handler shouldn't throw an OFE though
>> because it's not an error condition. But it doesn't!
>>
>> Oh, I bet I know why; the theory of the handler is somewhat off. If you
>> invoke /interface=bogusname:validate-address, it will work, because the
>> handler is (indirectly) registered under /interface=*. But if you do
>> /bogustype=public:validate-address, it doesn't work as expected as
>> nothing is registered under /bogustype=*. So you are seeing the standard
>> "unknown address" handling.
>
> Ok, it's a bit confusing. Normally you shouldn't see those WARN caused
> by the CLI (i.e. it does almost everything right :). But if you want to
> reproduce the issue, start a standalone server, connect the cli, stop
> the server and start the domain w/o re-connecting the cli, i.e. it'll
> still show [standalone at ...] prompt. Then press tab to complete commands.
>
> It'll check if the messaging subsystem is there (/subsystem=messaging)
> to include or exclude the jms commands. And it does it on every empty
> line tab-completion (the results could be cached though).

Yep; that's the scenario I describe. In a domain, address 
/subsystem=anything is equivalent to /boguschildtype=anything, since 
subsystem is not a valid child type of the root domain resource.

I think the solution is to make the address a param. This could be done 
without breaking the existing op by making it an optional parameter, 
with the value used to validate an address relative to the address being 
invoked against.

:validate-address(address=[(subsystem=messaging)])

That's less user friendly than /subsystem=messaging:validate-address, 
but I doubt somewhat nonsophisticated users will invoke this op.

Hmm, I'll look into an alternative: having handling of invalid 
address/op combos not trigger a WARN; perhaps that is easy to do.

>
> Alexey
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the jboss-as7-dev mailing list