Further to this,
On 11/09/2012 12:13, Nigel Deakin wrote:
> Here's another longstanding issue that I'd like to finish.
>
> You may remember that last May I made some proposals to clarify the meaning of the noLocal flag with durable subscriptions.
>
> The issue is summarised here:
> http://java.net/jira/browse/JMS_SPEC-65#action_339660
>
> and the changes that I made to the draft spec and javadocs are summarised here:
> http://java.net/jira/browse/JMS_SPEC-65#action_340590
>
> Here's a summary of the new spec:
>
> "When a durable subscription is created on a topic, the noLocal argument may be used to specify that messages published
> to the topic by its own connection or any other with the same client identifier will not be added to the durable
> subscription. If the client identifier is unset then setting noLocal to true has no effect."
>
> The only person who expressed any concern about this was Clebert who was concerned about backwards compatibility, and I
> parked this issue as a result. I've recently been in touch with Clebert and I think this is no longer a concern, so the
> changes can go ahead.
>
> However Clebert did mention one possible change. In JMS 2.0 we allow clientID to be unset when creating a durable
> subscription. Since the definition of noLocal is based on the clientID of the producer matching the clientID of the
> subscription, I originally proposed that
>
> "If the client identifier is unset then setting noLocal to true has no effect."
>
> However I am wondering whether this case should actually throw an exception, since it is probably better to throw an
> exception rather than silently ignore a parameter. I would therefore like to like to propose a small modification to all
> API methods which create a durable subscription as follows:
>
> "If the client identifier is unset then setting noLocal to true will cause a java.lang.IllegalArgumentException to be
> thrown."
I've now added this change to the draft spec and javadocs. In a private email Clebert suggested that the exception
should be a javax.jms.IllegalStateException rather than a java.lang.IllegalArgumentException since the problem is that
the connection is in the wrong state (client identifier is unset) rather than the value of noLocal being illegal. So
I've used this exception for the methods on Session and IllegalStateRuntimeException for the method on JMSContext.
With a bit of luck, this new feature is now fully-defined!
Nigel