Martijn,
On 23/08/2012 15:31, Martijn Verburg wrote:
> Hi Nigel,
>
> *CCing in our Adopt-a-JSR group*
>
> Apologies for the long delay in responding!
>
> <snip>
>
>>> So a few questions for the spec lead / EG:
>>>
>>> 1.) Is there a binary RI we can use? (some sort of Glassfish
>>> implementation I assume). Or so we build one from source out of SVN?
>>
>> The RI will be Open Message Queue (for the standalone JMS provider) and
>> GlassFish (as part of a full Java EE 7 implementation) and will follow the
>> existing open source processes of those projects.
>>
>> Implementation of JMS 2.0 features in those projects is in progress at
>> Oracle. I would expect an initial implementation containing some but not all
>> features to be available for JavaOne USA (end Sept), so if you want to
>> actually run some software then I would suggest you aim to hold your
>> workshop after then. The JMS 2.0 Public Draft is also due about then. (*)
>
> That's fine and I understand the Oracle delivery position well (love
> that slide!) :-)
>
> I'll be at JavaOne so perhaps we can meet up and discuss in person?
Certainly! (I hope you'll be coming to the technical session and the BOF as well).
>
>>> 2.) Are there any test frameworks/stubs/harnesses that are already used
>>> by the community?
>>
>> I'm not sure what kind of thing you have in mind, but there's nothing for
>> JMS 2.0 currently.
>
> I guess we'd be looking for a small app or test harness that helps people
> run test scenarios. So for example a stubbed out test harness that behaves
> as a producer/consumer/topic/queue/whatever would.
The JMS 2.0 API jar and javadocs are available on jms-spec.java.net, so people can try writing code, but there's nothing
to run until the RIs arrive.
>
> Is there something you're planning on using to prove the RI that can be
> shared?
In terms of simple examples, the simplified API examples in the JMS 2.0 spec chapter 11.4 would be a good place to
start. They are pretty simple, but making them available as a download (perhaps I will add them to the jms-spec source
repo) sounds a good idea.
(Note the latest spec is currently inconsistent with the latest API updates, I will update it shortly).
>
>>> 3.) Are there any particular areas that the EG are concerned about in
>>> terms of day-to-day developers using current draft of the spec? We tend
>>> to setup test scenarios that the developers need to pass and then
>>> simply observe them using the new API..
>>
>> I'm not sure quite how to answer this, but I would invite you to look at the
>> what's new section of the current draft.
>>
>> One of the biggest changes is the new JMSContext API, and support for
>> injection of JMSContext objects in Java EE. However these are intended for
>> ease-of-use rather than to support any particular use case that couldn't be
>> supported before.
>
> Yep, we're going to focus a bit on that and see if day-to-day developers
> genuinely find that easier to use. I'm also hoping to visit other areas of
> the spec (even some of the old spec) to see if there's anything else existing
> that causes extreme pain.
That would be great.
Comments on the parts of the spec what we're not changing would be welcome (I'm hoping people will raise these at the
BOF). Though these would need to go on the agenda for JMS 2.1.
Nigel
>
> Cheers,
> Martijn