activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-1403) Wildcard matching should always respect delimiters
Date Thu, 07 Sep 2017 14:46:00 GMT


ASF subversion and git services commented on ARTEMIS-1403:

Commit 983ec7eb888a8bacacb11156d90653b3006f4e44 in activemq-artemis's branch refs/heads/master
from [~cshannon]
[;h=983ec7e ]

ARTEMIS-1403 - Fix wildcard matching to always respect delimiters

The regular expressions for wildcard matching now properly respects the last
delimiter in a pattern and will not match a pattern missing the
delimiter by mistake

> Wildcard matching should always respect delimiters
> --------------------------------------------------
>                 Key: ARTEMIS-1403
>                 URL:
>             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

View raw message