Clebert,
On 14/09/2011 17:09, Clebert Suconic wrote:
> The only issue I see though, is how to be at the same time compatible
> with JMS 1.1 and JMS 2.
>
> I mean, if we need (for compatibility reasons) have to support both
> versions given the user's choice, the implementation will have several
> ifs that I don't like.
>
> (Say If I still want to deliver a jms-1.1 compatible implementation).
My intention is that if clientId is set then it will be used together with subscriptionName to uniquely identify the
durable subscription. If clientId is not set then only the subscriptionName is used to identify the durable subscription.
This means that applications written to work with 1.1 should continue to work with 2.0.
The only difference is that in 1.1 if a user fails to set clientId and then tries to create a durable subscription they
will get a JMSException. However in 2.0 this is valid. However since such an application isn't a valid JMS 1.1
application (i.e. you get an exception) I don't think we need worry to much about changing the behaviour in 2.0.
I hope that's acceptable.
>
> That starts another question: Do we need to be compatible with 1.1 or
> that will be just be up to each implementor?
I think broadly we are aiming for 1.1 compatibility, but exactly what this means is worth a separate discussion not
specific to this issue. I'll raise this separately.
Nigel