EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Stig Døssing
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?
Reply | Threaded
Open this post in threaded view
|

Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Claus Ibsen-2
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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Stig Døssing
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 <[hidden email]>
Sent: 26. september 2019 08:50
To: [hidden email]
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Claus Ibsen-2
Hi

Yeah it sounds like a good idea to try to normalize the pattern if it
resemble an uri pattern with query parameters, eg check for ? sign
etc.
You are welcome to log a JIRA and work on a PR

On Thu, Sep 26, 2019 at 9:15 AM Stig Døssing
<[hidden email]> wrote:

>
> 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 <[hidden email]>
> Sent: 26. september 2019 08:50
> To: [hidden email]
> 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 <[hidden email]> 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



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

RE: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Stig Døssing
Thanks, will do.

-----Original Message-----
From: Claus Ibsen <[hidden email]>
Sent: 26. september 2019 09:52
To: [hidden email]
Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Hi

Yeah it sounds like a good idea to try to normalize the pattern if it resemble an uri pattern with query parameters, eg check for ? sign etc.
You are welcome to log a JIRA and work on a PR

On Thu, Sep 26, 2019 at 9:15 AM Stig Døssing <[hidden email]> wrote:

>
> 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 <[hidden email]>
> Sent: 26. september 2019 08:50
> To: [hidden email]
> 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 <[hidden email]> 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



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Claus Ibsen-2
On Thu, Sep 26, 2019 at 10:16 AM Stig Døssing
<[hidden email]> wrote:
>
> Thanks, will do.
>

Did you create a JIRA ?

> -----Original Message-----
> From: Claus Ibsen <[hidden email]>
> Sent: 26. september 2019 09:52
> To: [hidden email]
> Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter
>
> Hi
>
> Yeah it sounds like a good idea to try to normalize the pattern if it resemble an uri pattern with query parameters, eg check for ? sign etc.
> You are welcome to log a JIRA and work on a PR
>
> On Thu, Sep 26, 2019 at 9:15 AM Stig Døssing <[hidden email]> wrote:
> >
> > 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 <[hidden email]>
> > Sent: 26. september 2019 08:50
> > To: [hidden email]
> > 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 <[hidden email]> 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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

RE: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Stig Døssing
No, not yet. I'll do it later today, don't have my Jira password with me.

-----Original Message-----
From: Claus Ibsen <[hidden email]>
Sent: 3. oktober 2019 09:34
To: [hidden email]
Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

On Thu, Sep 26, 2019 at 10:16 AM Stig Døssing <[hidden email]> wrote:
>
> Thanks, will do.
>

Did you create a JIRA ?

> -----Original Message-----
> From: Claus Ibsen <[hidden email]>
> Sent: 26. september 2019 09:52
> To: [hidden email]
> Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the
> pattern parameter
>
> Hi
>
> Yeah it sounds like a good idea to try to normalize the pattern if it resemble an uri pattern with query parameters, eg check for ? sign etc.
> You are welcome to log a JIRA and work on a PR
>
> On Thu, Sep 26, 2019 at 9:15 AM Stig Døssing <[hidden email]> wrote:
> >
> > 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 <[hidden email]>
> > Sent: 26. september 2019 08:50
> > To: [hidden email]
> > 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 <[hidden email]> 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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

RE: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Stig Døssing
Created https://issues.apache.org/jira/browse/CAMEL-14032.

-----Original Message-----
From: Stig Døssing <[hidden email]>
Sent: 3. oktober 2019 10:01
To: [hidden email]
Subject: RE: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

No, not yet. I'll do it later today, don't have my Jira password with me.

-----Original Message-----
From: Claus Ibsen <[hidden email]>
Sent: 3. oktober 2019 09:34
To: [hidden email]
Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

On Thu, Sep 26, 2019 at 10:16 AM Stig Døssing <[hidden email]> wrote:
>
> Thanks, will do.
>

Did you create a JIRA ?

> -----Original Message-----
> From: Claus Ibsen <[hidden email]>
> Sent: 26. september 2019 09:52
> To: [hidden email]
> Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the
> pattern parameter
>
> Hi
>
> Yeah it sounds like a good idea to try to normalize the pattern if it resemble an uri pattern with query parameters, eg check for ? sign etc.
> You are welcome to log a JIRA and work on a PR
>
> On Thu, Sep 26, 2019 at 9:15 AM Stig Døssing <[hidden email]> wrote:
> >
> > 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 <[hidden email]>
> > Sent: 26. september 2019 08:50
> > To: [hidden email]
> > 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 <[hidden email]> 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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

Onder SEZGIN
In reply to this post by Stig Døssing
yes i had been trapped recently. good to hear it will be improved

On Thu, Sep 26, 2019 at 10:15 AM Stig Døssing <[hidden email]>
wrote:

> 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 <[hidden email]>
> Sent: 26. september 2019 08:50
> To: [hidden email]
> 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 <[hidden email]>
> 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
>