[
https://issues.apache.org/jira/browse/QPID-8674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904480#comment-17904480
]
Robbie Gemmell commented on QPID-8674:
--------------------------------------
Your updated code snippets also have a logic mismatch with what you described.
The first code indicates the _size_ to be "large", and then has the selector
checking "... and not (size = 'small')", which you then say reduces to "... and
not (true)", however it actually reduces to "... and not(false)" since _size_
was "large" and so isnt equal to small, i.e false in this case (or undefined if
size was not set at all). The code would seem correct to say the result is true
in that case and fail the assertFalse (albeit, as follows, likely doing so for
the wrong reason currently).
Ignoring that and taking the reductions in isolation does seem to point to an
issue however, looking to boil down to the behaviour of the NOT handling.
I ran a comparison in a debugger with the selector "color = 'red' and not
(price = 200) and not (size = 'small')" to see how the parsers in Qpid Broker-J
and ActiveMQ Artemis (I believe their parsers were both based on the same
ActiveMQ 5 parser originally long long ago, but have differenced since)
initially parsed the selector into its components to later evaluate against the
message. The parser from Artemis indeed gave a significantly different parsed
interpretation for the selector, one not explained by their differing related
classes and logic handling. The NOT handling specifically was very different in
what it applied to, with BROKER-J applying the first NOT to everything after,
rather than just the price=200, which indeed seems wrong.
Comparing the parser grammar used to generate the parser code (but not the
surrounding non-generated logic that gets used with it), and ignoring some
expected feature related differenced between them and a typo, the _only_
notable difference between the two grammars actually looks to be specifically
\{_}in their NOT handling{_}.
That NOT handling difference in the grammar happens to also be the only thing
recently changed in the Broker-J parser, with it being updated for QPID-8656.
Seemingly based on questionable expectations; the report there was that using
"NOT property LIKE ..." didnt behave as expected, however the specific
documented way to do that particular comparison 'not like' check is using
"property NOT LIKE ..." so that change just seems questionable to begin with.
Reverting QPID-8656, the parser looked to start interpreting the "color = 'red'
and not (price = 200) and not (size = 'small')" selector in the expected manner
and in the same way as Artemis (allowing for their impl differences). I think
I'd be starting there.
> [Broker-J] Jms Selector Parsing - multiple AND's
> ------------------------------------------------
>
> Key: QPID-8674
> URL: https://issues.apache.org/jira/browse/QPID-8674
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-9.2.0
> Reporter: Kyrre
> Priority: Major
> Fix For: qpid-java-broker-9.2.1
>
> Attachments: selectorSyntax.patch
>
>
> When parsing a selector with 3 boolean expressions AND'ed together, the last
> expression is not taken into account.
> I have attached a patch file from the latest Github version of the main
> branch to demostrate the problem.
> In short, having a selector that evaluates (trueExpression) AND
> (trueExpression) AND (falseExpression) evaluates to TRUE.
> Patch of JMSSelectorFilterSyntaxTest.java below.
> [^selectorSyntax.patch]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
