[jms-dev] [jms] Eclipse Project for JMS


Ed Bratt
 

Reza,

Java EE issues from java.net JIRA projects were transferred to their corresponding GitHub issue trackers. The issues from JavaEE GitHub organization projects are being migrated over to Jakarta EE project repositories. JMS API issues in Jakarta EE are at this link. These are migrated after the initial code push. For many projects, this is still work in progress but they should find their way into Jakarta EE.

If you have issue IDs, the IDs should match the ID from the original java.net JIRA. The issues you had previously filed at java.net can be found by search with search-term "reza" (here's a link).

-- Ed


On 5/21/2018 4:22 AM, reza_rahman wrote:

Do you know if the Java.net JIRA issues are archived somewhere? That's really the best way for me to re-engage and state what I had in mind originally.

What I see missing at a high level are:
* Decoupling from EJB altogether.
* Standardizing parallelism, retries, dead letter queues and so on.
* Higher level declarative semantics for things like bulk processing, ordering, request-reply model using correlation ID/reply-to header and so on.

In addition we should look at the following:

* The reactive/flow control stuff the person from Lightbend had in mind vis-a-vis JMS.
* An analysis of what can be adopted from the likes of Kafka to make JMS more compelling to people now using those solutions instead of JMS. My layman's understanding is that it has mostly to do with quality of service than API as well as things like clustering and routing that JMS does not really specify. In fact it may be smart to make whatever API we come up with work with Kafka as part of DeltaSpike or MicroProfile.
* One issue with microservices seemingly is interoperability. Maybe it's time again to look to an AMQP, REST/WebSocket, gRPC or like binding for JMS.

Other than this, what you have I think is fine, although I sort of question the value of the CDI Event binding part. I suspect there would be far too much mapping to do in both directions. As always, it's probably a matter of prioritizing and tackling what time and resources allow.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: David Blevins <dblevins@...>
Date: 5/18/18 8:43 PM (GMT+01:00)
Cc: Richard Monson-Haefel <rmonson@...>
Subject: Re: [jms] Eclipse Project for JMS

[resending as it didn't make it to jms-spec@javaee.groups.io]

Hi Everyone!

The new Eclipse list for future JMS work is jms-dev@..., which you can subscribe to via sending an email to jms-dev-subscribe@....

We should make sure everyone does that, but as there are currently only 10 subscribers on that list, I think we should cc both lists for a short period of time.

High-level there's an effort in Jakarta EE overall to have projects put some thoughts together on the roadmap.  Understand this does not need to be perfect or exhaustive or permanent.  Just something to get us started and ensure technical direction is originating here.

For those who want a good resource on where we left off with JMS 2.1, here's the page we had been using to aggregate status:

- https://javaee.github.io/jms-spec/pages/JMS21

Essentially, the work that was underway was to create a completely annotation-driven API for consuming JMS messages styled after JAX-RS.  This would allow:

- Consumption of messages from multiple topics/queues in one class (like JAX-RS has @Path to allow multiple endpoints)
- Consumption of messages using specific Message types (no need to cast to TextMessage, just declare that)
- Ability to pass message headers into the methods (like JAX-RS has @PathParam, @HeaderParam, etc)
- Ability to convert from string to Java for those method params (like JAX-RS can eliminate "parsing" of string-to-java for method params)

This underwent at least 5 revisions.  Here's the latest:

- https://javaee.github.io/jms-spec/pages/JMSListener5

What wasn't underway, but I think we should add:

- Ability to convert the message itself to Java via JAXB or JSON-B (like JAX-RS can convert bodies to java based on content-type)

We discussed a handful of CDI related topics:

- Allowing the consumption of messages via CDI Events
- Potential custom scopes specific to JMS

We can do what we want, but that is more or less what was in motion before JMS 2.1 was officially shut down.

One thing I think we should correct is if we add this major new JAX-RS-styled message consumption API, it's probably bigger than a "point 1" release.  I.e. we should go big and call it JMS 3.0 instead of hiding it in a JMS 2.1.

This could be one of the major headlining things to come out of Jakarta EE, why go small.

Anyway, this is just an attempt to bootstrap a community conversation, so do speak up!  All ideas are on the table.


-David


> On May 17, 2018, at 11:14 AM, Richard Monson-Haefel <rmonson@...> wrote:
>
> Hi,
>
> If you are interested in contributing to the new expert group at the Eclipse Foundation, which will be defining JMS 3.0 for Jakarta EE, please send me an email. David Blevin’s is leading the effort .  At this time we are not formally forming the expert group, which is currently named “Eclipse Project for JMS”, but will have a voting process in place later. For now, we are looking to discuss the future of the specification and put together ideas for a rough roadmap to share with the Jakarta EE Project Management Comittee. If you or someone you know, wants to contribute to this effort please reply to me directly at rmonson@....
>
> Thank you,
>
> Richard Monson-Haefel
> Sr. Software Engineer
> Tomitribe
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>






_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev


Werner Keil
 

If this is about timing and scheduling, what is the benefit of java.time over java.util.concurrent.TimeUnit?

Werner 




On Mon, May 21, 2018 at 7:45 PM, Reza Rahman <reza_rahman@...> wrote:

Thanks so much Ed. Below are the two I would look at with regards to my original thinking. I am happy to explain anything that's unclear. Looking at the former JIRA issues, I am also reminded there are a few places in the JMS specification we could possibly use the Java SE 8 date/time API (details on the link Ed kindly posted).

* https://github.com/eclipse-ee4j/jms-api/issues/134

* https://github.com/eclipse-ee4j/jms-api/issues/154

On 5/21/2018 7:06 PM, Ed Bratt wrote:

Reza,

Java EE issues from java.net JIRA projects were transferred to their corresponding GitHub issue trackers. The issues from JavaEE GitHub organization projects are being migrated over to Jakarta EE project repositories. JMS API issues in Jakarta EE are at this link. These are migrated after the initial code push. For many projects, this is still work in progress but they should find their way into Jakarta EE.

If you have issue IDs, the IDs should match the ID from the original java.net JIRA. The issues you had previously filed at java.net can be found by search with search-term "reza" (here's a link).

-- Ed


On 5/21/2018 4:22 AM, reza_rahman wrote:
Do you know if the Java.net JIRA issues are archived somewhere? That's really the best way for me to re-engage and state what I had in mind originally.

What I see missing at a high level are:
* Decoupling from EJB altogether.
* Standardizing parallelism, retries, dead letter queues and so on.
* Higher level declarative semantics for things like bulk processing, ordering, request-reply model using correlation ID/reply-to header and so on.

In addition we should look at the following:

* The reactive/flow control stuff the person from Lightbend had in mind vis-a-vis JMS.
* An analysis of what can be adopted from the likes of Kafka to make JMS more compelling to people now using those solutions instead of JMS. My layman's understanding is that it has mostly to do with quality of service than API as well as things like clustering and routing that JMS does not really specify. In fact it may be smart to make whatever API we come up with work with Kafka as part of DeltaSpike or MicroProfile.
* One issue with microservices seemingly is interoperability. Maybe it's time again to look to an AMQP, REST/WebSocket, gRPC or like binding for JMS.

Other than this, what you have I think is fine, although I sort of question the value of the CDI Event binding part. I suspect there would be far too much mapping to do in both directions. As always, it's probably a matter of prioritizing and tackling what time and resources allow.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: David Blevins <dblevins@...>
Date: 5/18/18 8:43 PM (GMT+01:00)
Cc: Richard Monson-Haefel <rmonson@...>
Subject: Re: [jms] Eclipse Project for JMS

[resending as it didn't make it to jms-spec@javaee.groups.io]

Hi Everyone!

The new Eclipse list for future JMS work is jms-dev@..., which you can subscribe to via sending an email to jms-dev-subscribe@....

We should make sure everyone does that, but as there are currently only 10 subscribers on that list, I think we should cc both lists for a short period of time.

High-level there's an effort in Jakarta EE overall to have projects put some thoughts together on the roadmap.  Understand this does not need to be perfect or exhaustive or permanent.  Just something to get us started and ensure technical direction is originating here.

For those who want a good resource on where we left off with JMS 2.1, here's the page we had been using to aggregate status:

- https://javaee.github.io/jms-spec/pages/JMS21

Essentially, the work that was underway was to create a completely annotation-driven API for consuming JMS messages styled after JAX-RS.  This would allow:

- Consumption of messages from multiple topics/queues in one class (like JAX-RS has @Path to allow multiple endpoints)
- Consumption of messages using specific Message types (no need to cast to TextMessage, just declare that)
- Ability to pass message headers into the methods (like JAX-RS has @PathParam, @HeaderParam, etc)
- Ability to convert from string to Java for those method params (like JAX-RS can eliminate "parsing" of string-to-java for method params)

This underwent at least 5 revisions.  Here's the latest:

- https://javaee.github.io/jms-spec/pages/JMSListener5

What wasn't underway, but I think we should add:

- Ability to convert the message itself to Java via JAXB or JSON-B (like JAX-RS can convert bodies to java based on content-type)

We discussed a handful of CDI related topics:

- Allowing the consumption of messages via CDI Events
- Potential custom scopes specific to JMS

We can do what we want, but that is more or less what was in motion before JMS 2.1 was officially shut down.

One thing I think we should correct is if we add this major new JAX-RS-styled message consumption API, it's probably bigger than a "point 1" release.  I.e. we should go big and call it JMS 3.0 instead of hiding it in a JMS 2.1.

This could be one of the major headlining things to come out of Jakarta EE, why go small.

Anyway, this is just an attempt to bootstrap a community conversation, so do speak up!  All ideas are on the table.


-David


> On May 17, 2018, at 11:14 AM, Richard Monson-Haefel <rmonson@...> wrote:
>
> Hi,
>
> If you are interested in contributing to the new expert group at the Eclipse Foundation, which will be defining JMS 3.0 for Jakarta EE, please send me an email. David Blevin’s is leading the effort .  At this time we are not formally forming the expert group, which is currently named “Eclipse Project for JMS”, but will have a voting process in place later. For now, we are looking to discuss the future of the specification and put together ideas for a rough roadmap to share with the Jakarta EE Project Management Comittee. If you or someone you know, wants to contribute to this effort please reply to me directly at rmonson@....
>
> Thank you,
>
> Richard Monson-Haefel
> Sr. Software Engineer
> Tomitribe
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>






_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev



_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev



reza_rahman <reza_rahman@...>
 

Thanks so much Ed. Below are the two I would look at with regards to my original thinking. I am happy to explain anything that's unclear. Looking at the former JIRA issues, I am also reminded there are a few places in the JMS specification we could possibly use the Java SE 8 date/time API (details on the link Ed kindly posted).

* https://github.com/eclipse-ee4j/jms-api/issues/134

* https://github.com/eclipse-ee4j/jms-api/issues/154

On 5/21/2018 7:06 PM, Ed Bratt wrote:

Reza,

Java EE issues from java.net JIRA projects were transferred to their corresponding GitHub issue trackers. The issues from JavaEE GitHub organization projects are being migrated over to Jakarta EE project repositories. JMS API issues in Jakarta EE are at this link. These are migrated after the initial code push. For many projects, this is still work in progress but they should find their way into Jakarta EE.

If you have issue IDs, the IDs should match the ID from the original java.net JIRA. The issues you had previously filed at java.net can be found by search with search-term "reza" (here's a link).

-- Ed


On 5/21/2018 4:22 AM, reza_rahman wrote:
Do you know if the Java.net JIRA issues are archived somewhere? That's really the best way for me to re-engage and state what I had in mind originally.

What I see missing at a high level are:
* Decoupling from EJB altogether.
* Standardizing parallelism, retries, dead letter queues and so on.
* Higher level declarative semantics for things like bulk processing, ordering, request-reply model using correlation ID/reply-to header and so on.

In addition we should look at the following:

* The reactive/flow control stuff the person from Lightbend had in mind vis-a-vis JMS.
* An analysis of what can be adopted from the likes of Kafka to make JMS more compelling to people now using those solutions instead of JMS. My layman's understanding is that it has mostly to do with quality of service than API as well as things like clustering and routing that JMS does not really specify. In fact it may be smart to make whatever API we come up with work with Kafka as part of DeltaSpike or MicroProfile.
* One issue with microservices seemingly is interoperability. Maybe it's time again to look to an AMQP, REST/WebSocket, gRPC or like binding for JMS.

Other than this, what you have I think is fine, although I sort of question the value of the CDI Event binding part. I suspect there would be far too much mapping to do in both directions. As always, it's probably a matter of prioritizing and tackling what time and resources allow.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: David Blevins <dblevins@...>
Date: 5/18/18 8:43 PM (GMT+01:00)
Cc: Richard Monson-Haefel <rmonson@...>
Subject: Re: [jms] Eclipse Project for JMS

[resending as it didn't make it to jms-spec@javaee.groups.io]

Hi Everyone!

The new Eclipse list for future JMS work is jms-dev@..., which you can subscribe to via sending an email to jms-dev-subscribe@....

We should make sure everyone does that, but as there are currently only 10 subscribers on that list, I think we should cc both lists for a short period of time.

High-level there's an effort in Jakarta EE overall to have projects put some thoughts together on the roadmap.  Understand this does not need to be perfect or exhaustive or permanent.  Just something to get us started and ensure technical direction is originating here.

For those who want a good resource on where we left off with JMS 2.1, here's the page we had been using to aggregate status:

- https://javaee.github.io/jms-spec/pages/JMS21

Essentially, the work that was underway was to create a completely annotation-driven API for consuming JMS messages styled after JAX-RS.  This would allow:

- Consumption of messages from multiple topics/queues in one class (like JAX-RS has @Path to allow multiple endpoints)
- Consumption of messages using specific Message types (no need to cast to TextMessage, just declare that)
- Ability to pass message headers into the methods (like JAX-RS has @PathParam, @HeaderParam, etc)
- Ability to convert from string to Java for those method params (like JAX-RS can eliminate "parsing" of string-to-java for method params)

This underwent at least 5 revisions.  Here's the latest:

- https://javaee.github.io/jms-spec/pages/JMSListener5

What wasn't underway, but I think we should add:

- Ability to convert the message itself to Java via JAXB or JSON-B (like JAX-RS can convert bodies to java based on content-type)

We discussed a handful of CDI related topics:

- Allowing the consumption of messages via CDI Events
- Potential custom scopes specific to JMS

We can do what we want, but that is more or less what was in motion before JMS 2.1 was officially shut down.

One thing I think we should correct is if we add this major new JAX-RS-styled message consumption API, it's probably bigger than a "point 1" release.  I.e. we should go big and call it JMS 3.0 instead of hiding it in a JMS 2.1.

This could be one of the major headlining things to come out of Jakarta EE, why go small.

Anyway, this is just an attempt to bootstrap a community conversation, so do speak up!  All ideas are on the table.


-David


> On May 17, 2018, at 11:14 AM, Richard Monson-Haefel <rmonson@...> wrote:
>
> Hi,
>
> If you are interested in contributing to the new expert group at the Eclipse Foundation, which will be defining JMS 3.0 for Jakarta EE, please send me an email. David Blevin’s is leading the effort .  At this time we are not formally forming the expert group, which is currently named “Eclipse Project for JMS”, but will have a voting process in place later. For now, we are looking to discuss the future of the specification and put together ideas for a rough roadmap to share with the Jakarta EE Project Management Comittee. If you or someone you know, wants to contribute to this effort please reply to me directly at rmonson@....
>
> Thank you,
>
> Richard Monson-Haefel
> Sr. Software Engineer
> Tomitribe
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>






_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev



reza_rahman <reza_rahman@...>
 

There might not be any (or there might be). When those particular issues were filed, I did not have bandwidth for full analysis (and honestly I still kind of don't). I wanted the EG to look into it.

On 5/21/2018 7:58 PM, Werner Keil wrote:

If this is about timing and scheduling, what is the benefit of java.time over java.util.concurrent.TimeUnit?

Werner 




On Mon, May 21, 2018 at 7:45 PM, Reza Rahman <reza_rahman@...> wrote:

Thanks so much Ed. Below are the two I would look at with regards to my original thinking. I am happy to explain anything that's unclear. Looking at the former JIRA issues, I am also reminded there are a few places in the JMS specification we could possibly use the Java SE 8 date/time API (details on the link Ed kindly posted).

* https://github.com/eclipse-ee4j/jms-api/issues/134

* https://github.com/eclipse-ee4j/jms-api/issues/154

On 5/21/2018 7:06 PM, Ed Bratt wrote:

Reza,

Java EE issues from java.net JIRA projects were transferred to their corresponding GitHub issue trackers. The issues from JavaEE GitHub organization projects are being migrated over to Jakarta EE project repositories. JMS API issues in Jakarta EE are at this link. These are migrated after the initial code push. For many projects, this is still work in progress but they should find their way into Jakarta EE.

If you have issue IDs, the IDs should match the ID from the original java.net JIRA. The issues you had previously filed at java.net can be found by search with search-term "reza" (here's a link).

-- Ed


On 5/21/2018 4:22 AM, reza_rahman wrote:
Do you know if the Java.net JIRA issues are archived somewhere? That's really the best way for me to re-engage and state what I had in mind originally.

What I see missing at a high level are:
* Decoupling from EJB altogether.
* Standardizing parallelism, retries, dead letter queues and so on.
* Higher level declarative semantics for things like bulk processing, ordering, request-reply model using correlation ID/reply-to header and so on.

In addition we should look at the following:

* The reactive/flow control stuff the person from Lightbend had in mind vis-a-vis JMS.
* An analysis of what can be adopted from the likes of Kafka to make JMS more compelling to people now using those solutions instead of JMS. My layman's understanding is that it has mostly to do with quality of service than API as well as things like clustering and routing that JMS does not really specify. In fact it may be smart to make whatever API we come up with work with Kafka as part of DeltaSpike or MicroProfile.
* One issue with microservices seemingly is interoperability. Maybe it's time again to look to an AMQP, REST/WebSocket, gRPC or like binding for JMS.

Other than this, what you have I think is fine, although I sort of question the value of the CDI Event binding part. I suspect there would be far too much mapping to do in both directions. As always, it's probably a matter of prioritizing and tackling what time and resources allow.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: David Blevins <dblevins@...>
Date: 5/18/18 8:43 PM (GMT+01:00)
Cc: Richard Monson-Haefel <rmonson@...>
Subject: Re: [jms] Eclipse Project for JMS

[resending as it didn't make it to jms-spec@javaee.groups.io]

Hi Everyone!

The new Eclipse list for future JMS work is jms-dev@..., which you can subscribe to via sending an email to jms-dev-subscribe@....

We should make sure everyone does that, but as there are currently only 10 subscribers on that list, I think we should cc both lists for a short period of time.

High-level there's an effort in Jakarta EE overall to have projects put some thoughts together on the roadmap.  Understand this does not need to be perfect or exhaustive or permanent.  Just something to get us started and ensure technical direction is originating here.

For those who want a good resource on where we left off with JMS 2.1, here's the page we had been using to aggregate status:

- https://javaee.github.io/jms-spec/pages/JMS21

Essentially, the work that was underway was to create a completely annotation-driven API for consuming JMS messages styled after JAX-RS.  This would allow:

- Consumption of messages from multiple topics/queues in one class (like JAX-RS has @Path to allow multiple endpoints)
- Consumption of messages using specific Message types (no need to cast to TextMessage, just declare that)
- Ability to pass message headers into the methods (like JAX-RS has @PathParam, @HeaderParam, etc)
- Ability to convert from string to Java for those method params (like JAX-RS can eliminate "parsing" of string-to-java for method params)

This underwent at least 5 revisions.  Here's the latest:

- https://javaee.github.io/jms-spec/pages/JMSListener5

What wasn't underway, but I think we should add:

- Ability to convert the message itself to Java via JAXB or JSON-B (like JAX-RS can convert bodies to java based on content-type)

We discussed a handful of CDI related topics:

- Allowing the consumption of messages via CDI Events
- Potential custom scopes specific to JMS

We can do what we want, but that is more or less what was in motion before JMS 2.1 was officially shut down.

One thing I think we should correct is if we add this major new JAX-RS-styled message consumption API, it's probably bigger than a "point 1" release.  I.e. we should go big and call it JMS 3.0 instead of hiding it in a JMS 2.1.

This could be one of the major headlining things to come out of Jakarta EE, why go small.

Anyway, this is just an attempt to bootstrap a community conversation, so do speak up!  All ideas are on the table.


-David


> On May 17, 2018, at 11:14 AM, Richard Monson-Haefel <rmonson@...> wrote:
>
> Hi,
>
> If you are interested in contributing to the new expert group at the Eclipse Foundation, which will be defining JMS 3.0 for Jakarta EE, please send me an email. David Blevin’s is leading the effort .  At this time we are not formally forming the expert group, which is currently named “Eclipse Project for JMS”, but will have a voting process in place later. For now, we are looking to discuss the future of the specification and put together ideas for a rough roadmap to share with the Jakarta EE Project Management Comittee. If you or someone you know, wants to contribute to this effort please reply to me directly at rmonson@....
>
> Thank you,
>
> Richard Monson-Haefel
> Sr. Software Engineer
> Tomitribe
> --
> Richard Monson-Haefel
> http://twitter.com/rmonson
> http://www.tomitribe.com
> http://www.tomitribe.io
>






_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev



_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev




_______________________________________________
jms-dev mailing list
jms-dev@...
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jms-dev