[
https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594213#action_12594213
]
Arnaud Simon commented on QPID-1005:
------------------------------------
There are several ways of solving this issue:
- We can use the AMQP client ID as a connection ID only and only use the JMS
client ID for identifying durable subscriptions.
- We can lazily make the connection with the broker when the connection is
firstly used.
Alternatively we can use a property for ignoring setClientID so we are
compatible with legacy applications that don't rely on the ID being set on the
connection URL.
I suggest we do the later unless there is somebody that really requires
otherwise.
> Client ID
> ---------
>
> Key: QPID-1005
> URL: https://issues.apache.org/jira/browse/QPID-1005
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Affects Versions: M3
> Reporter: Arnaud Simon
> Fix For: M3
>
>
> JMS sepc says:
> ========================
> The preferred way to assign a JMS client's identifier is for it to be
> configured in a nclient-specific ConnectionFactory
> object. Alternatively, a nclient can set a connection's nclient identifier
> using a provider-specific value.
> ========================
> We currently assume that the client ID is set through the URL (if none is
> specified we then use a default one). We therefore always throw a
> IllegalStateException when an application tries to set it. I agree that this
> behavior respects the JMS specs however we fail to support some legacy JMS
> applications (i.e. a jms app that does set the client ID). Note that this is
> the case of the Sonic test harness that is used by a lot people when it comes
> to test our JMS implementation.
> I would therefore suggest that we let an application setting the client ID
> when it is not explicitly set on the URL.
> Suggestions/comments
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
