Re: [jms-dev] Jakarta Messaging Plan for version 3.1 (Jakarta EE 10)

[Rüdiger <snackbox@xxxxxxxxx>]

I also agree that we should first aim for small steps and see how far we can get in the fixed JEE 10 timeframe.

Apart from that I’m still in favor of a more radical change in the longer term. CDI events would be one way, but I think this introduces too many technical details into the business domain objects. I’d prefer to take a similar approach as MP REST Client did: use an interface to describe the required business functionality, both on the sending and receiving side; and annotations (that can be extracted into stereotypes) for the technical details, when necessary. The main difference to MP REST Client is that messages don’t directly return a value ;-)

This had already been proposed for the JMS 2.0 spec back in 2011, but it was probably ahead of its time. For details see https://github.com/t1/message-api


Rüdiger

> On 2021-05-07, at 01:37, Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx> wrote:
> 
> I agree with David that we most probably won't have enough time to implement anything significant for Jakarta EE 10 and that it's best to focus on the essential changes first (fixes, repeatable annotations) and separating the TCK to the JMS repository. We can work on features listed in [1] too and if they are ready, we can add them to plan via a Progress Review later as David suggests.
> 
> I'd like to prepare a draft of the plan for JMS 3.1 soon, so that we have at least a chance to join the Jakarta EE 10 release train.
> 
> We can discuss new features either in general on the github issue [1] or start a new thread on this mailing list for each specific proposal.
> 
> Ondro
> 
> [1] https://github.com/eclipse-ee4j/jms-api/issues/242
> 
> št 6. 5. 2021 o 22:48 Reza Rahman <reza_rahman@xxxxxxxxx> napísal(a):
> So do we think we reached some kind of consensus on which way to go? Do folks that have not chimed in yet have an opinion?
> 
> Either way, I will go though the current issue tracker and triage issues this week. I don’t think that has been done in a while. If other folks can join in, that would be awesome.
> 
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
> 
> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
> 
>> On May 4, 2021, at 8:13 PM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
>> 
>> 
>> I think the feature that is most important to have is a CDI based alternative to MDB. There are several other issues we discussed at length in the JCP days, but I think they are less important by comparison: https://jakartaee-ambassadors.io/guide-to-contributing-to-jakarta-ee-10/.
>> 
>> If we can't do that, we should go though the issue tracker and gather some minor fix items. I definitely think we should be able to able to gather enough of those for a small maintenance release.
>> 
>> Reza Rahman
>> Jakarta EE Ambassador, Author, Blogger, Speaker
>> 
>> Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
>> 
>> On 5/4/2021 7:29 PM, Ondro Mihályi wrote:
>>> Hi all,
>>> 
>>> I noticed that Messaging didn't submit a plan for review for Jakarta EE 10. Do we still want to submit a plan so that we can deliver a new version of JMS in EE 10?
>>> 
>>> I think that plans should have been submitted by April 15 but we may still try to submit a plan because JMS is a very important Jakarta EE specification. It wouldn't be a good message if JMS didn't get any update for EE 10, at least with very minor updates.
>>> 
>>> Because we didn't have any discussion about new features recently, we could introduce something from the roadmap outlined by David in 2019 in a github issue. I would only go after things that are rather straightforward, long overdue, and already well documented. So from the items in that issue, I suggest to consider only:
>>> 	• Annotation-Based API for Consuming Messages #243
>>> 	• CDI Message Consumers #244
>>> 	• MessagingClient #249
>>> Additionally, we can support repeatable annotations in some cases, e.g. for JMSDestinationDefinition.
>>> 
>>> What do you think? Do you want me to start working on a plan for Messaging 3.1 that we would submit to the https://github.com/jakartaee/specifications repository?
>>> 
>>> Should we plan to add the new features as I suggested above? Or it's much more that we can handle and it's better to submit a plan just to add fixes and possibly support repeatable annotations?
>>> 
>>> What do you think?
>>> 
>>> Ondro
>>> 
>>> 
>>> _______________________________________________
>>> jms-dev mailing list
>>> 
>>> jms-dev@xxxxxxxxxxx
>>> 
>>> To unsubscribe from this list, visit 
>>> https://www.eclipse.org/mailman/listinfo/jms-dev
> _______________________________________________
> jms-dev mailing list
> jms-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev
> _______________________________________________
> jms-dev mailing list
> jms-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jms-dev