On 08/12/2011 16:31, John D. Ament wrote:
> Nigel,
>
> Should this also include the definition of a JMSRuntimeException that represents a runtime issue.
>
> John
It does exactly that. Please see pages 5-6 for a list of the new runtime exceptions, and the Javadocs for full details
of when they are thrown.
(On p25 I call it javax.jms.RuntimeException. That should be javax.jms.JMSRuntimeException. I've got it right everywhere
else.)
Nigel
>
> On Thu, Dec 8, 2011 at 10:07 AM, Reza Rahman <reza_rahman_at_lycos.com <mailto: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
>
> 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
> 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 <http://www.avg.com>
> Version: 2012.0.1873 / Virus Database: 2102/4666 - Release Date: 12/07/11
>
>
>
>