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.

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@...] 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev