[jira] Commented: (CAMEL-1756) getEndpoint() should match for singleton endpoints even if url does not contain params

["Claus Ibsen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/CAMEL-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52458#action_52458 ] 

Claus Ibsen commented on CAMEL-1756:
------------------------------------

I looked into this beforehand, especially the seda endpoint.

It was a bit confusing as the seda endpoint is kinda like an internal JMS queue, so the uri notations is kinda like a queue name.
So the queue name was the unique but the parameters didnt matter.

But in Camel land the endpoints differ, here is why

Lets imagine we have this endpoint already registered
- seda:foo

And you want to lookup this endpoint
- seda:foo?concurrentConsumers=5

As the code is now, the two endpoints do not match and you create a 2nd endpoint. They are also different as the first endpoint is *not* using concurrent consumers.
But the 2nd does.

So I do not think there is a nice and clean way of doing this. 

> getEndpoint() should match for singleton endpoints even if url does not contain params
> --------------------------------------------------------------------------------------
>
>                 Key: CAMEL-1756
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-1756
>             Project: Apache Camel
>          Issue Type: Improvement
>    Affects Versions: 1.6.1, 2.0-M2
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>             Fix For: 1.6.2, 2.0.0
>
>
> When one uses endpoint injection, if the url does not exactly match, the CamelContext will not find the endpoint (and create a new one).
> I think singleton Endpoint(s) should not be registered with the full url, just with the url stripped of parameters, since they are mostly configuration and not necessarily relevant to the producer.  Also if the configuration of a singleton endpoint will change slightly, an update/recompile of the producer code is no longer necessary.
> I cannot think of a situation in which this improvement would cause problems.  I have a fix for this but I'll wait a few days.  Thoughts?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.