I would agree this defiantly should not be done client side, the feature needs
to be fully and properly implemented broker side.
I've been reviewing the so called JMS2 client at TomEE, and there are just so
many spec issues with the implementation, like some of those mentioned by
Chris, theres actually quite a few nasty surprises people will get tbh, its
asking for trouble.
As well I hope that any implementation done, is not just for openwire, but
works with the AMQP 1.0 connections that many users are now adopting.
Like wise i hope that if there's a commitment to add the feature, that there's
a commitment to ensure the openwire clients are updated not just the Java
one.....
I know work has gone into properly supporting JMS 2.0 semantics to NMS for AMQP
which fully works with Artemis, theres been some bugs found before its
released, but the point being people will expect that the open wire is
supported, or if not at least the AMQP implementation in the ActiveMQ broker
also properly implemented.
I would def not be providing a positive vote in a release vote for the current
proposal, of just doing some client hack to make it look like, but not meet JMS
2.0 spec, its asking for issues.
Thanks
Mike
On 19 May 2021 at 16:09, Timothy Bish <tabish...@gmail.com> wrote:
On 5/19/21 6:17 AM, Christopher Shannon wrote:
Moving back to dev list again...
Yes we had talked about it before in terms of the client side but it wasn't
clear in this thread as your original answer on this thread was "ActiveMQ
5.17.0 will support JMS 2.0." with no caveats or clarification to mention
that it would not be full support. Seeing as how this was on the users list
that would be a bit misleading to users.
Also, I still don't really know what the point of "client side" support is
because you can use the JMS 2.0 jar with ActiveMQ as long as you don't call
the new methods. Looking at that code you linked it seems like the new
methods (like shared subscription creation) just delegate to the old JMS
1.1 methods such as in
https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2/TomEESession.java
That behavior seems odd and confusing to me because if a user is calling
methods to make a shared subscription or shared durable but it wasn't
supported I think it would be much preferable to just throw an error or
something vs delegating back. It seems way worse to allow users to call
those methods with no errors as a user of the library would (no surprise)
be expecting it to provide a shared subscription and it doesn't with no
indidication. If someone is writing an application and their business logic
is asking for a shared subscription but we don't provide it then that is
very different semantics and would most likely break the application so I
think that's a pretty bad idea overall so I really don't see why we would
want to do that.
I'd have to agree here, the client shouldn't do the wrong thing just to
pretend that it did something. If it can't do it then it should fail so
that people know what the limitations are, and also the limitations
should be clearly and explicitly documented where people can find it.
Other people can chime in but I would be very likely to veto a code change
for client support that simply delegates 2.0 methods to 1.1 methods.
On Wed, May 19, 2021 at 12:09 AM Jean-Baptiste Onofre <j...@nanthrax.net>
wrote:
By the way, correct me if I’m wrong, but it’s what we discussed last year:
start with the client the side, and then move forward for server side.
What we planned in 5.16.x will be in 5.17.x.
Regards
JB
Le 19 mai 2021 à 06:05, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit :
Hi,
The first step is at least the client support, similar to what have been
done on OpenEJB:
https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2
<
https://github.com/apache/tomee/tree/master/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2
This allow TomEE to work with ActiveMQ using JMS 2.0.
So, the proposal is to have a two steps work:
1. Support JMS 2.0 client side, it will help in tomee, karaf, etc
2. Step by step implement server side support
IMHO, 1 would be good step forward already and it works fine for a while
in tomee. It will already allow us to update the spec.
Regards
JB
Le 18 mai 2021 à 21:09, Christopher Shannon <
christopher.l.shan...@gmail.com> a écrit :
What exactly are you proposing? Full support would be a tremendous
amount
of work. I started a thread on this already a while back here:
http://activemq.2283324.n4.nabble.com/DISCUSS-JMS-2-0-support-in-5-x-going-forward-td4757779.html
My issue here is the lack of clarity. I have no clue what you are
proposing
but it needs to be defined so we don't mislead users by claiming there
is
JMS 2.0 support when there isn't. I listed out possible paths forward in
that other thread.
On Tue, May 18, 2021 at 12:04 PM Jean-Baptiste Onofre <j...@nanthrax.net>
wrote:
It’s something that we already discussed and I moved forward on the PR.
I propose to move forward on JMS 2.0 support.
If the community agree, and tests are fine, I don’t see any issue to
support it in 5.17.0 as best effort.
Anyway, I will propose the PR, and see when to include it.
Regards
JB
Le 18 mai 2021 à 17:36, Christopher Shannon <
christopher.l.shan...@gmail.com> a écrit :
Since when is JMS 2.0 supposed to be supported by 5.17.0?
None of the features are implemented on the server side for the new
API
calls. This was brought up in a dev discussion that there won't be JMS
2.0
support on the server side in this release.
On Tue, May 18, 2021 at 11:29 AM Jean-Baptiste Onofre <
j...@nanthrax.net>
wrote:
He’s not PMC but committer, so he can help anyway ;)
Regards
JB
Le 18 mai 2021 à 17:23, COURTAULT Francois <
francois.courta...@thalesgroup.com> a écrit :
Hello,
I don't think Romain is still the PMC for TomEE.
Best Regards.
-----Original Message-----
From: Jean-Baptiste Onofre <j...@nanthrax.net>
Sent: mardi 18 mai 2021 17:19
To: us...@activemq.apache.org
Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0 or
3.0
?
Hi,
I’m sure I can ask help from Romain about TomEE releases ;)
Regards
JB
Le 18 mai 2021 à 17:09, COURTAULT Francois <
francois.courta...@thalesgroup.com> a écrit :
Hello Jean-Baptiste,
We are using ActiveMQ in TomEE context.
So I am just curious about when this version could be included in
TomEE
releases. I will push for that.
Best Regards.
-----Original Message-----
From: Jean-Baptiste Onofre <j...@nanthrax.net <mailto:
j...@nanthrax.net>>
Sent: mardi 18 mai 2021 17:05
To: us...@activemq.apache.org <mailto:us...@activemq.apache.org>
Subject: Re: Which activeMQ (not Artemis) version will be JMS 2.0
or
3.0 ?
Hi,
The purpose of the RC is to cut an early release (kind of "cut
SNAPSHOT") to allow users to test it before the first "official"
release.
What I can propose to you is:
1. I need couple of weeks to open the PRs and merge it (I’m on
JDK11
now, identifying/fixing/disabling some tests) 2. When done, I will
inform
you on the mailing list allowing you to test using the SNAPSHOTs
(5.17.0-SNAPSHOT) 3. If I don’t see any blocker on SNAPSHOT, then I
will
move forward on 5.17.0 release
Does it sound good to you ?
Regards
JB
Le 18 mai 2021 à 16:59, Simon Billingsley
<simon.billings...@matrixx.com.INVALID> a écrit :
Thanks for the details information.
I am interested in the Log4J 2 upgrade.
How long does the release take after the RC process normally?
Best regards,
Simon.
On 18 May 2021, at 15:53, Jean-Baptiste Onofre <j...@nanthrax.net
<mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net <mailto:
j...@nanthrax.net
<mailto:j...@nanthrax.net <mailto:j...@nanthrax.net><mailto:
j...@nanthrax.net
<mailto:j...@nanthrax.net>>>> wrote:
Hi François,
ActiveMQ 5.17.0 will support JMS 2.0.
Basically, what I’m planning for ActiveMQ 5.17.0:
- JDK11 build
- Spring 5
- Log4j2
- JMS 2.0
About date target, I’m working on JDK11 build now and the other
PRs
will follow. I would like to submit a first 5.17 RC end of June.
Regards
JB
Le 18 mai 2021 à 16:48, COURTAULT Francois <
francois.courta...@thalesgroup.com <mailto:
francois.courta...@thalesgroup.com> <mailto:
francois.courta...@thalesgroup.com <mailto:
francois.courta...@thalesgroup.com>><mailto:
francois.courta...@thalesgroup.com <mailto:
francois.courta...@thalesgroup.com> <mailto:
francois.courta...@thalesgroup.com <mailto:
francois.courta...@thalesgroup.com>>>> a écrit :
Hello,
The question to be answered is in the Subject.
Best Regards.
--
Tim Bish
