Nigel,
Great -- we could just use that instead of Google docs, etc then...
Cheers,
Reza
On 8/4/2011 12:09 PM, Nigel Deakin wrote:
> Yes. Although our discussions are intended to be open, and individuals
> can make contributions at any stage, I think the EG needs to reach a
> degree of consensus before actively inviting comments on anything,
> otherwise we risk confusing the wider community.
>
> jms-spec.java.net contains a wiki which you should be able to add
> content to, if you think that would be useful.
>
> Nigel
>
>
> On 04/08/2011 16:54, Reza Rahman wrote:
>> Nigel,
>>
>> Yes - of course. I was actually thinking you should do the blog on
>> behalf of the EG once we have discussed it a bit
>> (perhaps on Java.net). If you are OK with it, we can get it
>> syndicated with TSS, JavaLobby and InfoQ to reach a wider
>> audience.
>>
>> Cheers,
>> Reza
>>
>>
>> On 8/4/2011 11:31 AM, Nigel Deakin wrote:
>>> Reza,
>>>
>>> Can you please address your proposals to the EG initially?
>>>
>>> Nigel
>>>
>>> On 04/08/2011 16:21, Reza Rahman wrote:
>>>> Nigel,
>>>>
>>>> Thanks for posting this. John and I will start work on it ASAP.
>>>> We'll try to put this on Google doc/some other public
>>>> space so we can all review progress and collaborate. I am thinking
>>>> it should be two different documents for the two
>>>> separate approaches. In fact, once we have a bit more detail, it
>>>> might not be a bad idea to publish the proposals as
>>>> blogs and get community feedback?
>>>>
>>>> Cheers,
>>>> Reza
>>>>
>>>>
>>>> On 8/4/2011 4:55 AM, Nigel Deakin wrote:
>>>>> Here are some minutes from a phone call that John, Reza and I had
>>>>> yesterday. One-line-summary: Reza and John have
>>>>> agreed to work together and produce a more detailed proposal along
>>>>> the lines described below, which could then be
>>>>> reviewed by this EG. Many thanks! Nigel
>>>>>
>>>>>
>>>>>
>>>>> On the call: Nigel, John, Reza
>>>>> Minute taker: Nigel
>>>>>
>>>>> Reza and John have offered to work together to develop proposals
>>>>> to address "(JMS_SPEC-33) Improving the JMS API with
>>>>> API simplifications, annotations and CDI"
>>>>>
>>>>> The purpose of this call was to agree on the scope of that
>>>>> proposal, and a suitable phasing.
>>>>>
>>>>> Scope
>>>>> -----
>>>>>
>>>>> The proposal would be aimed at improving the way that JMS was used
>>>>> in Java EE applications.
>>>>>
>>>>> Improving the way that JMS is used in Java SE applications was
>>>>> considered hightly desirable but a secondaery
>>>>> requirement.
>>>>>
>>>>> Phasing
>>>>> -------
>>>>>
>>>>> Nigel explained that he thought any proposals should be divided
>>>>> into two phases:
>>>>>
>>>>> Phase 1: Improving the API for sending and for synchronously
>>>>> receiving messages
>>>>> Phase 2: Improving the API for asynchronously receiving messages
>>>>>
>>>>> Phase 1 was a higher priority than Phase 2 because whereas Java EE
>>>>> applications currently have no choice other than to
>>>>> use the JMS API for sending and for synchronously receiving
>>>>> messages, applications that asynchronously receive
>>>>> messages can (and must) use MDBs which are declarative and already
>>>>> completely hide the JMS API.
>>>>>
>>>>> Dependencies
>>>>> ------------
>>>>>
>>>>> Phase 1 could probably be built as a later on top of the existing,
>>>>> or slightly modified, JMS API. It would have
>>>>> minimal dependencies on the Java EE platform or on other Java EE
>>>>> specs.
>>>>>
>>>>> Phase 2 would require close integration with the Java EE platform,
>>>>> for the same reason that means MDBs are implemented
>>>>> in the platform rather than the JMS provider. There would be
>>>>> dependencies on changes to the Java EE platform and to
>>>>> other Java EE specs.
>>>>>
>>>>> Nigel explained that he was advocating this two-stage approach
>>>>> becayse Phase 2 looked as if it would take more time
>>>>> and require more negotiation with other groups, and he didn't want
>>>>> this to prevent the EG making rapid progress with
>>>>> Phase 1.
>>>>>
>>>>> Phase 1 in more detail
>>>>> ----------------------
>>>>>
>>>>> We discussed Phase 1 in more detail. It was agreed there were two
>>>>> main possible approaches:
>>>>>
>>>>> 1. A new API which used resource injection and annotation. The
>>>>> SEAM JMS project was suggested as an example of this
>>>>> approach. Reza had already published some examples of such an API.
>>>>>
>>>>> 2. A simplified "plain old" Java API, not using resource injection
>>>>> or annotation, which provided various utility
>>>>> methods for sending and synchronously receiving messages. The
>>>>> Spring JMSTemplate class was suggested as an example of
>>>>> this approach.
>>>>>
>>>>> In both cases, whilst the goal would to devise something that
>>>>> would use the existing JMS API, this would not preclused
>>>>> small changes to the JMS API if this would allow a simpler API
>>>>> overall. One suggestion providing message factory
>>>>> methods which didn't depend on a Session object.
>>>>>
>>>>> It was likely that the RI for both approaches could be used by
>>>>> other vendors, though it was not intended to precluse
>>>>> vendors offering their own implementations.
>>>>>
>>>>> There was also a third option, to develop a completely new JMS
>>>>> API, not using resource injection or annotation, and
>>>>> NOT built on top of the existing API. This wasn't something EG
>>>>> members have suggested so far and although it might be
>>>>> worth including in any review of options, it didn't seem a likely
>>>>> option.
>>>>>
>>>>> Timscales
>>>>> ---------
>>>>>
>>>>> Reza and John suggested that would aim to have some proposals that
>>>>> they could share with the EG in about two weeks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> No virus found in this message.
>>>>> Checked by AVG - www.avg.com
>>>>> Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date:
>>>>> 08/03/11
>>>>>
>>>>>
>>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1391 / Virus Database: 1518/3810 - Release Date: 08/04/11
>>>
>>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1391 / Virus Database: 1518/3810 - Release Date: 08/04/11
>
>