You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org> on 2008/05/02 14:24:55 UTC
[jira] Created: (QPID-1005) Client ID
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.
[jira] Resolved: (QPID-1005) Client ID
Posted by "Aidan Skinner (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aidan Skinner resolved QPID-1005.
---------------------------------
Resolution: Fixed
> 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.
[jira] Commented: (QPID-1005) Client ID
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593766#action_12593766 ]
Martin Ritchie commented on QPID-1005:
--------------------------------------
setClientID has to throw ISE because we actually perform the connection during the constructor. There is no way to change the the client id once the connection has been established.
> 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.
[jira] Commented: (QPID-1005) Client ID
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593777#action_12593777 ]
Arnaud Simon commented on QPID-1005:
------------------------------------
JMS says:
If a client sets the client identifier explicitly, it must do so immediately after it creates the connection and before any other action on the connection is taken.
Why can't we change the client ID once the connection has been established? I don't think this is the case with 0.10 actually. I thought the client ID was only used for durable subscription.
> 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.
[jira] Commented: (QPID-1005) Client ID
Posted by "Robert Greig (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593894#action_12593894 ]
Robert Greig commented on QPID-1005:
------------------------------------
Is this not a protocol issue, i.e. we set the client identifier in the connection.start-ok method and have no provision to do it after connection establishment?
> 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.
[jira] Commented: (QPID-1005) Client ID
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594215#action_12594215 ]
Arnaud Simon commented on QPID-1005:
------------------------------------
I have added a property for ignoring the operation setClientID. We can resolve this issue unless somebody disagrees with that solution.
> 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.
[jira] Commented: (QPID-1005) Client ID
Posted by "Arnaud Simon (JIRA)" <qp...@incubator.apache.org>.
[ 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.
[jira] Commented: (QPID-1005) Client ID
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ 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.