On 22.06.2011, at 16:53, Nigel Deakin wrote:
> On 22/06/2011 15:18, Adrian Johnson wrote:
>> Adam,
>>
>> On 6/21/11 5:33 AM, Adam Bien wrote:
>>>> o Removal of Queue and Topic specific interfaces in favor of general ones
>>> +1 Interesting idea. It means - the client does not know whether it is PTP or PubSub?
>>
>> It's not that it doesn't *know* whether it is PtP or PubSub, it's more that why should that matter when it comes to
>> creating Connections and Sessions?
>
> Essentially, this is about competing the unification of domains what was started with JMS 1.1. The JMS 1.1 spec, section 1.5 "What is New in JMS 1.1?" says:
>
> "In previous versions of JMS, client programming for the Point-to-Point and Pub/Sub domains was done using similar but separate class hierarchies. In JMS 1.1, there is now a domain-independent approach to programming the client application. This provides several benefits:
>
> "• For the client programmer, a simpler programming model
> "• The ability to engage queues and topics in the same transaction, now that
> they can be created in the same session
> "• For the JMS provider, increased opportunity to optimize implementations by pooling thread management
>
> "To take advantage of these features, the developer of JMS clients needs to use the domain-independent or “common” APIs. In the future, some of the domain-specific APIs may be deprecated.
>
> "In JMS 1.1, all of the classes and methods from JMS 1.0.2b are retained to provide backward compatibility. The semantics of the two messaging domains are retained; the expected behavior of a Point-to-Point domain and a Pub/Sub domain remain the same, as described in Chapter 5, “JMS Point-to-Point Model,” and Chapter 6, “JMS Publish/Subscribe Model.”"
>
>
> I think what Adrian is suggesting is that we go ahead and deprecate the "domain-specific APIs" as was suggested in the 1.1 spec. This means deprecating QueueConnectionFactory. QueueConnection, QueueSession, TopicConnectionFactory, TopicConnection and TopicSession, and their XA equivalents. It would also mean deprecating QueueReceiver.
+1 for deprecation.
>
> However I note that Connection.createDurableSubscriber() returns a TopicSubscriber, not a MessageConsumer, which looks to me like a mistake, so we might need to tidy this and no doubt other things up at the same time.
thanks for clarification!,
adam
>
> Nigel
>
>
Independent Consultant, Speaker, Java Champion
Weblog: blog.adam-bien.com
press: press.adam-bien.com
eMail: abien_at_adam-bien.com
twitter: twitter.com/AdamBien
Mobile: 0049(0)170 280 3144
Author of:
"Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking Best Practices"