[jboss-as7-dev] validate-address warning

[Emanuel Muckenhuber]

Hmm, i actually added this operation, so i can stick it at the top of an 
composite operation, where it would fail immediately rather than 
somewhere during the validation stage. In particular our secure .cli 
scripts, since there are no further scripting capabilities. However i 
thought i registered this operation as Private - obviously out of this 
context this behavior does not make much sense.

On 07/18/2011 06:39 PM, Brian Stansberry wrote:
> 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
>
>