Seems reasonable to me. As JMS_SPEC-65 now defines consistent nolocal
behaviour, it's best to inform the user they're requesting this
behaviour but are not configured for it.
Nick
Nicholas Wright
Senior Consultant
/C2B2 Consulting Ltd
/
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."
>
> Comments, please!
>
> Nigel