Quick comments below...
On 24/11/2011 00:31, John D. Ament wrote:
> Nigel,
>
> I have some comments in line:
>
> On Tue, Nov 22, 2011 at 12:41 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto: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
>
> 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.
Agreed.
> * 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?
I'm not sure what solution is best, but we should certainly have a look at pluggable marshalling. I was impressed by the
number of people who raised this issue.
> * 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?
Many products do this, but there are no standards. Is this something that JMS should attempt to standardise? What type
of applications would benefit?
>
>
> * 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?
This has come up before, and I agree this is something we should consider. I'll make a note and we can come back to this
after the early draft.
>
> * 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?
I suppose you would pass in the MessageProducer as an argument. However I can't see the benefit in using
Message.send(MessageProducer) instead of MessageProducer.send(Message), especially when we already have the latter.
Nigel
>
>
> Nigel
>
>
>
>