You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2008/05/02 15:02:55 UTC
[jira] Commented: (QPID-1005) Client ID
[ https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593767#action_12593767 ]
Martin Ritchie commented on QPID-1005:
--------------------------------------
I guess we could reconnect if someone calls setClientID .. provided the connection hasn't been started but that does sound a bit hacky.
> 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.