OK, let's try again :-)
Currently we have two methods on Session which return a TopicSubscriber:
TopicSubscriber createDurableSubscriber(Topic topic, java.lang.String name)
TopicSubscriber createDurableSubscriber(Topic topic, java.lang.String name, java.lang.String messageSelector, boolean
noLocal)
To allow us to deprecate and propose for removal all the domain-specific classes (apart from Queue and Topic), we need
to provide new versions of this method which return a MessageConsumer.
We can't simply add new methods with the same name which return a MessageConsumer since the compiler would consider
these duplicate methods.
Reza suggests we add:
Option 1
--------
MessageConsumer createConsumer(Topic topic, java.lang.String name)
MessageConsumer createConsumer(Topic topic, java.lang.String name, java.lang.String messageSelector, boolean noLocal)
However there's potential confusion between the first of those methods and the existing method to create an ordinary
consumer with a message selector:
MessageConsumer createConsumer(Destination destination, java.lang.String messageSelector)
The compiler would allow it, but if the user tried to create a durable subscription using a variable which was really a
Topic but which was declared as Destination then the wrong method would be called.
We could either live with this, or we could use:
Option 2
--------
MessageConsumer createDurableConsumer(Topic topic, java.lang.String name)
MessageConsumer createDurableConsumer(Topic topic, java.lang.String name, java.lang.String messageSelector, boolean
noLocal)
Any preferences?
Nigel
On 19/09/2011 18:43, reza_rahman_at_lycos.com wrote:
> +1. I think createConsumer() that takes a Topic (as opposed to a generic JMS Destination) and a durable subscriber
> name as argument might be fine.
>
>
> Sep 19, 2011 12:56:07 PM, jsr343-experts_at_jms-spec.java.net wrote:
>
> On 19/09/2011 13:20, Ruediger zu Dohna wrote:
>> Nigel,
>>
>> wouldn't existing code need to do a downcast from MessageConsumer to TopicSubscriber?
>
> Er, yes. So it would! I wasn't thinking properly...
>
> I was trying to avoid users having to change their code. Perhaps we need to add a new method and deprecate the old
> one.
>
> Thanks,
>
> Nigel
>
>>
>> On 19.09.2011 13:40, Nigel Deakin wrote:
>>> On 16/09/2011 19:58, reza_rahman_at_lycos.com wrote:
>>>> +1. However, it would not be 100% backwards compatible, would it?
>>>>
>>> What kind of compatibility would this break? Existing application code would not need to be changed.
>>>
>>> Nigel
>>>
>>>
>>>> Sep 16, 2011 02:35:46 PM, jsr343-experts_at_jms-spec.java.net <mailto:jsr343-experts_at_jms-spec.java.net> wrote:
>>>>
>>>> I have logged the following JIRA issue: http://java.net/jira/browse/JMS_SPEC-51
>>>>
>>>> Here is the description, which I think is self-explanatory (I originally raised this as part of JMS_SPEC-47,
>>>> but I am now separating it out to a separate trackable issue).
>>>>
>>>> There were no objections when I first suggested this, but if anyone has any comments please make them now.
>>>>
>>>> ---------------------- In JMS 1.1 the method Session.createDurableSubscriber() returns a TopicSubscriber, not a
>>>> MessageConsumer.
>>>>
>>>> This is the only "domain-independent" method in the whole JMS 1.1 API which depends on a "domain-specific"
>>>> interface. This dependency prevents the "domain-specific" interfaces being removed from JMS as proposed in
>>>> JMS_SPEC-47
>>>>
>>>> It is therefore proposed to modify this method to return a MessageConsumer. Since this is a supertype of
>>>> TopicSubscriber it should not break existing applications. ----------------------
>>>>
>>>>
>>>> Nigel
>>>>
>>>>