[
https://issues.apache.org/jira/browse/ARTEMIS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated ARTEMIS-1403:
--------------------------------------------
Description:
Here is what I originally posted on the dev list. There is a bug with wildcard
matching that will return that a string is a match to a pattern even though
there are extra characters after the last delimiter.
>From my original post:
{quote}I noticed a difference with wildcard matching in Artemis from 5.x and I
think the Artemis version is wrong.
Let's take the following wildcard pattern as an example in Artemis: a.b.c.#
Pattern Matches?
a.b.c yes
a.b.c.d yes
a.b.cabd yes
Example in ActiveMQ 5.x: a.b.c.>
Pattern Matches?
a.b.c yes
a.b.c.d yes
a.b.cabd no
It does not make sense to me that a.b.cabd would match a.b.c.#. This happens
because the matching logic just replaces .# with .* in a regex matching pattern
so it matches 0 or many characters. There is a delimiter there so I think the
5.x approach is correct. Also maybe we should allow user's to be able to plug
in custom matching logic to override the default? (This is something i can do
in a PR){quote}
Note that this change will not affect matching 0 or more words. So a.b.c
should still match a.b.c.#
It would also still be nice to be able to plug in custom matching logic if a
user has custom requirements but that would be done in a different PR.
was:
Here is what I originally posted on the dev list. There is a bug with wildcard
matching that will return a string is a match to a pattern even though the last
delimiter is missing.
>From my original post:
{quote}I noticed a difference with wildcard matching in Artemis from 5.x and I
think the Artemis version is wrong.
Let's take the following wildcard pattern as an example in Artemis: a.b.c.#
Pattern Matches?
a.b.c yes
a.b.c.d yes
a.b.cabd yes
Example in ActiveMQ 5.x: a.b.c.>
Pattern Matches?
a.b.c yes
a.b.c.d yes
a.b.cabd no
It does not make sense to me that a.b.cabd would match a.b.c.#. This happens
because the matching logic just replaces .# with .* in a regex matching pattern
so it matches 0 or many characters. There is a delimiter there so I think the
5.x approach is correct. Also maybe we should allow user's to be able to plug
in custom matching logic to override the default? (This is something i can do
in a PR){quote}
The one exception that should still apply is that '#' means 0 or more words so
a.b.c.# should still match a.b.c for example. It would also still be nice to
be able to plug in custom matching logic if a user has custom requirements but
that would be done in a different PR.
> Wildcard matching should always respect delimiters
> --------------------------------------------------
>
> Key: ARTEMIS-1403
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1403
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.3.0
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Priority: Minor
> Fix For: 2.4.0
>
>
> Here is what I originally posted on the dev list. There is a bug with
> wildcard matching that will return that a string is a match to a pattern even
> though there are extra characters after the last delimiter.
> From my original post:
> {quote}I noticed a difference with wildcard matching in Artemis from 5.x and
> I think the Artemis version is wrong.
> Let's take the following wildcard pattern as an example in Artemis: a.b.c.#
> Pattern Matches?
> a.b.c yes
> a.b.c.d yes
> a.b.cabd yes
> Example in ActiveMQ 5.x: a.b.c.>
> Pattern Matches?
> a.b.c yes
> a.b.c.d yes
> a.b.cabd no
> It does not make sense to me that a.b.cabd would match a.b.c.#. This happens
> because the matching logic just replaces .# with .* in a regex matching
> pattern so it matches 0 or many characters. There is a delimiter there so I
> think the 5.x approach is correct. Also maybe we should allow user's to be
> able to plug in custom matching logic to override the default? (This is
> something i can do in a PR){quote}
> Note that this change will not affect matching 0 or more words. So a.b.c
> should still match a.b.c.#
> It would also still be nice to be able to plug in custom matching logic if a
> user has custom requirements but that would be done in a different PR.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
