Nigel,
Should this also include the definition of a JMSRuntimeException that
represents a runtime issue.
John
On Thu, Dec 8, 2011 at 10:07 AM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> I'll take a look as soon as I can.
>
>
> On 12/8/2011 9:51 AM, Nigel Deakin wrote:
>
>> I've created the following JIRA issue to cover the work to devise a new
>> simplified API.
>> http://java.net/jira/browse/**JMS_SPEC-64<http://java.net/jira/browse/JMS_SPEC-64>
>>
>> The JIRA issue describes some goals for the API:
>>
>> * To reduce the number of objects needed to send and receive messages,
>> and in particular to combine the JMS 1.1 {{Connection}}, {{Session}},
>> {{MessageProducer}} and {{MessageConsumer}} objects as much as possible.
>>
>> * To take advantage of the fact that this is a new API to simplify method
>> signatures and make other simplifications which cannot be made to the old
>> API because it would break backwards compatibility.
>>
>> * To maintain a consistent style with the existing API where possible so
>> that users of the old API feel it to be an evolution which that can learn
>> quickly.
>>
>> * To support, and offer benefits to, both Java EE and Java SE
>> applications.
>>
>> * To allow resource injection to be exploited in those environment which
>> support it, whilst still offering significant improvements for those
>> environments which do not.
>>
>> * To provide the option to send and receive message payloads to be sent
>> and received directly without the need to use {{javax.jms.Message}} objects.
>>
>> * To remove as much as possible the need to catch {{JMSException}} on
>> method calls
>>
>> * To be functionally complete. The old API will remain to provide
>> backwards compatibility. However the new API is intended to be functionally
>> as complete as the old JMS 1.1 API. Users should not need to switch back to
>> the old API to perform an operation that is unavailable in the new API.
>>
>> As you know we've had quite a few discussions on this already, and as
>> promised I've written up a proposal. This is described in a pdf document at:
>> http://java.net/downloads/jms-**spec/Simplified%20API/**
>> JMS20SimplifiedAPIv1.pdf<http://java.net/downloads/jms-spec/Simplified%20API/JMS20SimplifiedAPIv1.pdf>
>> with a corresponding set of javadocs at:
>> java.net/projects/jms-spec/**downloads/download/Simplified%**
>> 20API/jms-2.0-javadoc.jar<http://java.net/projects/jms-spec/downloads/download/Simplified%20API/jms-2.0-javadoc.jar>
>>
>> Please take a look and make comments.
>>
>> Comments are welcome on anything I've written, but I should say from the
>> outset that some aspects of the proposals are further advanced than others.
>> In particular I haven't suggested how we might exploit the new API using
>> CDI. I hope that the proposed API makes this easier to achieve but I hope
>> to have a discussion about what we might do.
>>
>> The proposals also suggest a simple API for sending and receiving message
>> payloads directly but I think this needs some more work.
>>
>> Thanks,
>>
>> Nigel
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1873 / Virus Database: 2102/4666 - Release Date: 12/07/11
>>
>>
>>
>