+1 to everyone Mike said. Implementing a hack makes no sense and advertising JMS 2.0 support with that would not be a good idea. I agree that we should fully support the spec before advertising as JMS 2.0 if that is the plan. This would require all of the client/protocol changes and server side/datastore changes to be done.
I've been using the JMS 2.0 jar with ActiveMQ 5.x for several years with no problems. I just exclude the 1.1 jar and use the 2.0 jar and don't call the new methods...done. So certainly if that makes it easier for things like Karaf we can distribute the 2.0 jar with the unsupported exceptions thrown. I don't think anyone has an issue distributing the JMS 2.0 jar as long as it's clear we don't actually support JMS 2.0 Just to reiterate Mike's point because this is important and there seems to be a lot of confusion about this on the Jira thread (AMQ-7309) about what is and isn't required when users request a feature: There is no obligation to provide anything just because a user requests it. It's up to the PMC to decide what is and isn't provided and PMC members have full veto power over code changes with valid justification. On Sat, May 22, 2021 at 3:23 AM Michael André Pearce <[email protected]> wrote: > Just a note, I have no issue in updating the JMS dependency to a newer > one, for class-path reasons, as long as new JMS 2.0 methods and features > implement exceptions, rather than hacking or trying to get "like" > behaviours. > > But we cannot brand, advertise or announce JMS 2.0 compatibility in any > form of ActiveMQ 5, for that full broker TCK compliance would be needed. > > > On 22 May 2021 at 7:59, Michael André Pearce > <[email protected]> wrote: > > Hi JB, > > I disagree here, the ultimate burden of maintenance is down to the > committers and pmc. > > Just because a user requests something, doesn't mean it has to be rushed > in, with some hack, or even accepted. Kafka project rejects many proposals > via their KIP process and other projects also. Like wise ive had some of my > own request / proposal in this project itself rejected. > > Clearly as seen with TomEE some hack can be done, but then the burden of > issues and maintenance is on them, there is nothing stopping them doing > that. > > Tbh i see two routes here, for users wanting JMS 2.0 supported. > > 1) Support and help those to migrate to ActiveMQ Artemis, there's now many > organisations who have made this migration I'm sure if someone is having > some issue there's help, which was originally the intent of its adoption > and still in my view the best idea here. > > 2) Take our time, and implement JMS 2.0 properly in ActiveMQ 5 "Classic" > properly ensuring it meets the TCK before release. > > Best > Mike > > > On 22 May 2021 at 5:53, Jean-Baptiste Onofre <[email protected]> wrote: > > Hi Mike, > > Anyway, as it’s requested by our users, we have to move forward about > that. That’s the JMS 2.0 imps part but my main concern is also the > dependency. For instance, camel-jms is JMS 2.0 and running in spring-boot > or karaf with ActiveMQ brings JMS 1.1 and 2.0 dependencies in the same > runtime. > > I hear Chris and your points, thanks for that. So I propose to move > forward with a first PR. > I will start by implementing some OperationNotSupportedException in the > new methods, and then adding better support step by step. > > Regards > JB > > Le 22 mai 2021 à 01:42, Michael André Pearce > <[email protected]> a écrit : > > > > 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 <[email protected]> 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 > < > 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 <[email protected]> > > 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 <[email protected]> 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 > >< > > > 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 < > > [email protected] <mailto:[email protected]>> > 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 > < > 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 <[email protected]> > > 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 < > > [email protected] <mailto:[email protected]>> > 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 < > > [email protected] <mailto:[email protected]>> > > wrote: > > > He’s not PMC but committer, so he can help anyway ;) > > > Regards > > JB > > > Le 18 mai 2021 à 17:23, COURTAULT Francois < > > [email protected] <mailto: > [email protected]>> a écrit : > > Hello, > > > I don't think Romain is still the PMC for TomEE. > > > Best Regards. > > > -----Original Message----- > > From: Jean-Baptiste Onofre <[email protected]> > > Sent: mardi 18 mai 2021 17:19 > > To: [email protected] <mailto:[email protected]>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 < > > [email protected] <mailto: > [email protected]>> 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 <[email protected] <mailto: > > [email protected] <mailto:[email protected]>>> > > Sent: mardi 18 mai 2021 17:05 > > To: [email protected] <mailto:[email protected]> <mailto: > [email protected]> > > 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 > > <[email protected]> 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 <[email protected] > > <mailto:[email protected]> <mailto:[email protected] <mailto: > > [email protected] <mailto:[email protected]><mailto:[email protected] <mailto: > [email protected]><mailto: > > [email protected] <mailto:[email protected]><mailto:[email protected]>>>> > 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 < > > [email protected] <mailto: > [email protected]> <mailto: > > [email protected] <mailto: > [email protected]>> <mailto: > > [email protected] <mailto: > [email protected]> <mailto: > > [email protected] <mailto: > [email protected]>>><mailto: > > [email protected] <mailto: > [email protected]> <mailto: > > [email protected] <mailto: > [email protected]>> <mailto: > > [email protected] <mailto: > [email protected]> <mailto: > > [email protected] <mailto: > [email protected]>>>>> a écrit : > > Hello, > > > The question to be answered is in the Subject. > > > Best Regards. > > > > > > -- > > Tim Bish > > > >
