Hi Mike,

So we agreed ;) The first round is to upgrade the dependency and throw 
OperationNotSupportedException for new methods.

The "JMS support" announcement will stand only when we will implement all 
methods.

Anyway, that’s a effort worth to do (and I already started), so, let’s just try 
to move forward.

Regards
JB

> Le 22 mai 2021 à 09:22, Michael André Pearce 
> <[email protected]> a écrit :
> 
> 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>
>>>>>>  
>>>>>> <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>><
>>>>>>> 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]> 
>>>>>>> <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>
>>>>>>>  
>>>>>>> <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]> 
>>>>>>>>>> <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]> <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]> 
>>>>>>>>>>>> <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]> 
>>>>>>>>>>>>> <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]> 
>>>>>>>>>>>> <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]> 
>>>>>>> <mailto:[email protected]>>>
>>>>>>>>>>>>>> Sent: mardi 18 mai 2021 17:05
>>>>>>>>>>>>>> To: [email protected] <mailto:[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]> 
>>>>>>>>>> <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] 
>>>>>>>>>>>> <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
>>>>> 
>>> 

Reply via email to