Date   

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

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


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

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



Re: Eclipse Project for JMS

reza_rahman <reza_rahman@...>
 

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)
To: jms-spec@javaee.groups.io, jms-dev@...
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
>





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

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



Re: [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


Re: Eclipse Project for JMS

David Blevins
 

[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


Re: Separate JMS orga in GitHub

Werner Keil
 

Nigel,

Thanks for the update. It looks like several of the community members including myself are owners of this organization, so if a better place for these repositories could be found, I'd be happy to help with their transition like I assisted Dmitry with JSON-P.

Currently there are 3 repositories
https://github.com/jms-spec/jms-examples
https://github.com/jms-spec/jms-proposals
and
https://github.com/jms-spec/jms-spec.github.io
(somehow it does not seem to render a correct page, so either it has no HTML content or is otherwise broken)

If the JavaEE organization was OK for at least the 2 repositories, they could be moved there. 
Please have a look at https://github.com/jms-spec/jms-examples/graphs/contributors and https://github.com/jms-spec/jms-proposals/graphs/contributors
It seems only Ivar and Andy from Tomitribe ever contributed code. Both (Tomitribe represented by David, but they're a corporate JCP and EC member, so I assume the JSPA covers Andy, too) are JCP Members and (via Tomitribe) also members of the JSR 368 EG, so please ask the lawers if necessary, but their contribution looks safe to use in the JCP context.

Werner


Re: Separate JMS orga in GitHub

Nigel Deakin
 

On 30/05/2017 14:01, Werner Keil wrote:
Hi,
Just wondering, if the separate GitHub organization https://github.com/jms-spec contains any difference from what is now under https://github.com/javaee ?
Following the shutdown of java.net, the source code repository has been converted to GIT and is now at https://github.com/javaee/jms-spec

The https://github.com/javaee organisation in GitHub is emerging as the common place for Oracle-led spec and Java EE projects. The Java EE platform spec, Open Message Queue and GlassFish are all there.

The JMS spec issue tracker is at
https://github.com/javaee/jms-spec/issues

The website is at
https://javaee.github.io/jms-spec/
(I'm still doing some conversion work and updates here: so it might look a little unfinished and out-of-date at the moment. This was previously a wiki but is now a "GitHub pages" site).

The email list is (of course) here
https://javaee.groups.io/g/jms-spec

The GitHub project at https://github.com/jms-spec is an independent initiative, not one I am involved with (or Oracle), so I don't know what's there. (Feel free to use this list to discuss it).

Most seems examples or proposals which are currently not considered in Java EE (maybe in EE9, maybe later or never depending on the plans for JMS)
So moving them to https://github.com/javaee seems wrong, but maybe there was another "examples" or Java EE related place for them instead of a dedicated GitHub organization?
I don't think there is any profound reason why this kind of material couldn't be accommodated on the "official" repository (or website). (However I need to mention the legal statement about contributions at https://javaee.github.io/jms-spec/CONTRIBUTING)

I'll give an update to this list when I finish tidying up the new website. It's great to be on GitHub at last...

Nigel

Regards,
Werner


Separate JMS orga in GitHub

Werner Keil
 

Hi,

Just wondering, if the separate GitHub organization https://github.com/jms-spec contains any difference from what is now under https://github.com/javaee ?

Most seems examples or proposals which are currently not considered in Java EE (maybe in EE9, maybe later or never depending on the plans for JMS)
So moving them to https://github.com/javaee seems wrong, but maybe there was another "examples" or Java EE related place for them instead of a dedicated GitHub organization?

Regards,
Werner

1 - 9 of 9