You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Stig Døssing <st...@systematic.com> on 2019/09/26 05:43:40 UTC

EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

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?

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

Posted by Stig Døssing <st...@systematic.com>.
Created https://issues.apache.org/jira/browse/CAMEL-14032. 

-----Original Message-----
From: Stig Døssing <st...@systematic.com> 
Sent: 3. oktober 2019 10:01
To: users@camel.apache.org
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 <cl...@gmail.com>
Sent: 3. oktober 2019 09:34
To: users@camel.apache.org
Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

On Thu, Sep 26, 2019 at 10:16 AM Stig Døssing <st...@systematic.com> wrote:
>
> Thanks, will do.
>

Did you create a JIRA ?

> -----Original Message-----
> From: Claus Ibsen <cl...@gmail.com>
> Sent: 26. september 2019 09:52
> To: users@camel.apache.org
> 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 <st...@systematic.com> 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 <cl...@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 <st...@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
>
>
>
> --
> 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

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

Posted by Stig Døssing <st...@systematic.com>.
No, not yet. I'll do it later today, don't have my Jira password with me.

-----Original Message-----
From: Claus Ibsen <cl...@gmail.com> 
Sent: 3. oktober 2019 09:34
To: users@camel.apache.org
Subject: Re: EndpointHelper.matchEndpoint doesn't normalize the pattern parameter

On Thu, Sep 26, 2019 at 10:16 AM Stig Døssing <st...@systematic.com> wrote:
>
> Thanks, will do.
>

Did you create a JIRA ?

> -----Original Message-----
> From: Claus Ibsen <cl...@gmail.com>
> Sent: 26. september 2019 09:52
> To: users@camel.apache.org
> 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 <st...@systematic.com> 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 <cl...@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 <st...@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
>
>
>
> --
> 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

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

Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 26, 2019 at 10:16 AM Stig Døssing
<st...@systematic.com> wrote:
>
> Thanks, will do.
>

Did you create a JIRA ?

> -----Original Message-----
> From: Claus Ibsen <cl...@gmail.com>
> Sent: 26. september 2019 09:52
> To: users@camel.apache.org
> 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 <st...@systematic.com> 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 <cl...@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 <st...@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
>
>
>
> --
> 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

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

Posted by Stig Døssing <st...@systematic.com>.
Thanks, will do.

-----Original Message-----
From: Claus Ibsen <cl...@gmail.com> 
Sent: 26. september 2019 09:52
To: users@camel.apache.org
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 <st...@systematic.com> 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 <cl...@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 <st...@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



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

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

Posted by Claus Ibsen <cl...@gmail.com>.
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
<st...@systematic.com> 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 <cl...@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 <st...@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



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

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

Posted by Onder SEZGIN <on...@gmail.com>.
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 <st...@systematic.com>
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 <cl...@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 <st...@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
>

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

Posted by Stig Døssing <st...@systematic.com>.
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 <cl...@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 <st...@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

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

Posted by Claus Ibsen <cl...@gmail.com>.
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
<st...@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