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.