On 14/12/2011 01:46, Reza Rahman wrote:
> Looks like a very good start if we decide to go this route (which I am not entirely sure is wise).
Can you please clarify what aspect of this you are uncertain about: the whole idea of a new API, or my particular proposals?
> Definitely think more
> early community feedback is needed -- perhaps via blogging/articles/speaking (I can help if needed).
There's still a piece missing. I'd like to propose some built-in CDI producers to allow MessagingContexts to be
injected. I hope that this will be pretty straightforward, but I'd like help from the CDI experts on this group on this.
With that piece added, I think we might have something definitely worth seeking wider views on. However I'd like to
achieve a consensus from the EG before going too far in that direction. If the EG is unconvinced on this I doubt the
community will be.
I'm thinking of proposing a conference call for EG members where I can present this whole API proposal, answer questions
and where people can make comments. How about early next week? Or would people prefer to wait until the new year?
(Notwithstanding the above, I'd welcome comments at any time from anyone who reads this email)
Nigel
>
> More detailed feedback to come soon...
>
> 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
>>
>> 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
>>
>>
>