Nigel,
I have some comments in line:
On Tue, Nov 22, 2011 at 12:41 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> As you may know, I was at Devoxx 2011 last week in Antwerp, Belgium, where
> I have a talk on "What's (probably) coming in Java Message Service 2.0".
>
> I've uploaded the slides to the project download page:
> http://java.net/projects/jms-**spec/downloads/download/JMS2.**
> 0Devoxx2011.pdf<http://java.net/projects/jms-spec/downloads/download/JMS2.0Devoxx2011.pdf>
>
> This essentially covers the same content as the presentation that Reza,
> Clebert and I have at JavaOne last month, except that I added a new slide
> to cover the "simplified API" that we started discussing a week or two ago.
> I appreciate that we are still brainstorming on that but I thought it was
> worth mentioning.
>
> I also reorganised the material to focus on the ease-of-use changes and
> new messaging features and downplay the rather less interesting work we've
> been doing on application server integration and configuration.
>
> There was a lot of interest, with a very good attendance and many
> questions at the talk and afterwards. Here are some of the comments that
> have reached me one way or another (voice, email, JIRA, twitter etc). If
> anyone reading this wants to add further comments or elaborate on the
> comments below please do.
>
> Negative comments:
>
> * There's not much here. It didn't deserve an hour-long talk. Boring. The
> speaker spent a lot of time on trivial issues. Yawn.
>
> * The code fragments in the slide were full of syntax errors!
>
> * Providing backwards compatibility is a bad idea as it reduces the scope
> to make useful changes
>
> I think we just need to find a comfortable in between where we support
backwards compatibility but make room for new. LIkely updated API will do
this. Its definitely more difficult to do this when defining an API vs
tooling.
> * If you're providing backwards compatibility, why are you changing the
> version number from 1 to 2? This will break existing OSGI-based JMS
> applications since OSGI will see the new version number and assume that
> existing applications are incompatible with JMS 2.0.
>
> Specific suggestions on existing proposals:
>
> * (JMS_SPEC-36) The callback method BatchMessageListener.**onMessages(Message[]
> messages): passing in an array is so passé. Need to pass in something like
> a List<Message> instead.
>
> * (JMS_SPEC-43) The callback method AcknowledgeListener.**onAcknowlege(Message
> message) - I think onSendAcknowledge would be a better name to avoid
> confusion with message consume acknowledge when using "acknowledge"
>
> Other suggestions:
>
> * It should be possible to build modular applications in a Java EE
> environment which use JMS to distribute work from one module to another.
> SEDA-style, perhaps. (This was mentioned at the Java EE BOF)
>
>
If you look at my old email regarding integrating CDI's event model, this
would be one of the capabilities.
> * Marshalling 1: JMS should have support for pluggable
> marshalling/unmarshalling like in Spring JMSTemplate.
> * Marshalling 2: Is it really necessary to create a TextMessage every time
> you want to send a String? Why not overload the send method or define it as
> send(Object) and establish a mechanism to turn an object into a stream?
> Something like MessageBodyReader's and MessageBodyWriter's in JAX-RS. As
> for the receive, I think one way would be to define it as: <T> T
> receive(Class<T> c).
>
>
I agree, it shouldn't be. For XML/JSON, could we integrate JAXB using a
JAXBContext? Perhaps standardize on a contentType attribute?
> * Do we really want to allow a application to be able to specify the
> physical name of a queue or topic? This will upset the administrators of
> our WebSphere MQ installation.
>
Yes, we really do :-)
>
> * New feature: Need new API for management and monitoring (queue depth,
> max queue message size, delete messages etc)
>
Isn't this already exposed in mbeans?
>
> * New feature: Need to support XPath selectors on body of XML TextMessages
>
I brought it up before... why not just standardize on an XMLMessage type?
>
> * New feature: Need to suppot regexp selectors on body of arbitrary
> TextMessages
>
> * New feature: Move the send() method onto the Message object.
Where do you want to send it to?
>
>
> Nigel
>
>
>
>