Hi Nigel,
That all sounds great, we'll keep sorting out some of the logistics
for running something over here and when the RI gets closer we'll dive
into the detail.
Looking forward to helping out!
Cheers,
Martijn
On 24 August 2012 10:29, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> 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