Hi Claus,
I don't need to match on the query parameters, and your workaround is fine. My
code happened to try to match the query parameters, since I have the endpoint
URI in a constant that I use in both the test and the route definition.
I think it's pretty surprising that you can put the exact same URI string into
the route's from(), and the NotifyBuilder's from(), and end up not getting a
match. I'm asking whether we can/should try to fix this weird behavior, so
other people don't get caught out by it? For example, we could try to normalize
the pattern in EndpointHelper.matchEndpoint if it parses as a URI, we could do
it in NotifiyBuilder.from instead, or we could add a note to the Javadoc for
NotifyBuilder.from that tells people that if they're passing a URI it should be
normalized. The parameter naming (endpointUri) and Javadoc for NotifyBuilder
indicates that passing a URI to match is one of the expected ways to use that
method.
-----Original Message-----
From: Claus Ibsen <claus.ib...@gmail.com>
Sent: 26. september 2019 08:50
To: users@camel.apache.org
Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern
parameter
Hi
Its a pattern and not an endpoint uri, eg you can use sjms* to match all jsms
components etc.
Why do you want to match on the query parameters, why not just say
sjms2://queue:my-queue-name*
On Thu, Sep 26, 2019 at 7:43 AM Stig Døssing <stig.doss...@systematic.com>
wrote:
>
> Hi,
>
> I'm trying to use NotifyBuilder for a test, and am running into a
> matching issue regarding the "from" method. My route looks like
>
> From( "sjms2:queue:my-queue-name?transacted=true&consumerCount=1")
> //processing here
>
> I use NotifyBuilder like this:
>
> NotifyBuilder notifyBuilder = new NotifyBuilder(context)
>
> .from("sjms2:queue:my-queue-name?transacted=true&consumerCount=1")
> .whenDone(1)
> .create()
>
> Followed by a call to matches(). When I run the test, the NotifyBuilder fails
> to match.
> The NotifyBuilder uses the EndpointHelper to match from endpoint URIs, and
> the call I'm seeing return false has the following parameters:
>
> EndpointHelper.matchEndpoint(context, uri =
> "sjms2://queue:my-queue-name?consumerCount=1&transacted=true", pattern
> = "sjms2:queue:my-queue-name?transacted=true&consumerCount=1")
>
> I would expect these values to match, but the EndpointHelper handles
> reordered query parameters by normalizing the "uri" parameter, but not the
> "pattern" parameter. As the "uri" parameter is already normalized, these
> values end up not matching.
>
> Should I raise an issue for this, or is this a known limitation?
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
