I think the approach is sound. I don’t see a lot of JMS-v2.0-as-a-minumum-version dependency in many 3rd party systems that integrate with JMS. They tend to use the v1.1 API method signatures anyway. IMHO throwing an UnsupportedException is a reasonable for the client-side JMS 2.0-specific methods for Chris’ point 1.
As for claiming ActiveMQ 5.x as “Supports JMS 2.0"— I think using Virtual Topics in approach #3 sounds reasonable to consider ActiveMQ 5.x as “Supports JMS 2.0" on the server-side. Other JMS v2.0 brokers use queues to back durable topic subscriptions, and make the same claim (ie IBM MQ). Also, ActiveMQ 5.x optionally uses a similar pattern with MQTT to be backed by Virtual Topics so it would not be setting a new precedent within ActiveMQ or the industry in general to call it “Supports JMS 2.0” by using a queue to back the shared topic subscription. -Matt Pavlovich > On Jun 25, 2020, at 9:06 AM, Jean-Baptiste Onofré <[email protected]> wrote: > > Hi, > > Thanks Chris for bringing this up. > > First, a quick update about JMS 2.0: client API compatibility is almost > done. I tested in Karaf, Camel and standalone Java and so far so good. > > My first intention when I proposed the JMS 2.0 support is first on > client side, as least to allow client to use JMS 2.0 API. > > About the specific features from JMS 2.0, the first step I did is to > return OperationNotSupportedException for now. So it's mostly Chris' > point 1. > > In term of roadmap, I tried to follow recommendation and feedback from > everyone. So roughly, that's my intention/understanding: > > - 5.16.0: JDK 11 support at runtime > - 5.16.x: first JMS 2.0 client side support (before 5.17.0). > - 5.17.0: JDK 11 support at both build and runtime and improved JMS 2.0 > support (even if not complete on broker side ;)). > > I'm ready to move forward on (3), but I think it's worth to create PR > and merge what I started already. > > Thoughts ? > > Regards > JB > > > On 25/06/2020 15:10, Christopher Shannon wrote: >> There seems to be some confusion on what the plan is for JMS 2.0 support in >> 5.x so I figured it was worth starting a discussion on it. >> >> First, targeting a complete implementation of "full" JMS 2.0 support for >> 5.17.0 is not very realistic in my opinion. I think 5.17.0 needs to go out >> faster than 5.16.0 did as for one thing it is starting to get annoying to >> have to use JDK 8 to build it. If JMS 2.0 support is going to happen that's >> probably going to take a few releases along the way with increasing >> functionality for each one and there is still a discussion that needs to >> happen on what will actually be done and the effort level. The main level >> of effort is dealing with the new shared subscription semantics. >> >> For example, in order of increasing effort: >> *1)* We could just add basic API compatibility with the JMS 2.0 jar but >> don't really implement many features at all (maybe have unsupported >> exceptions thrown if a new method is called) which i think was the goal of >> 5.16.1. Note that this isn't really buying much as a user can simply use >> the JMS 2.0 jar now with 5.x and just not call the new methods (which is >> what I personally do) >> *2)* We could have the Java client fake it by using Virtual topics to >> create shared subscriptions. So if a user calls off to the shared sub api >> call it would just subscribe to the matching queue it needed. The downside >> to this is it's done all client side so would only work for the Java client >> and not any other open wire clients and is pretty hacky. Seems better to >> just have the user use virtual topics natively than this way. >> *3)* Another approach could be to add full JMS 2.0 support to OpenWire and >> upgrade the client/server to the new version but use Composite destinations >> or Virtual topics on the server to provide the functionality. The idea >> being when the server receives the new openwire commands to create a shared >> subscription it fakes it by leveraging the composite destination or virtual >> topic feature to mimic the behavior. The main functionality to add would be >> client side, openwire itself and the management/tracking logic on the >> server side to map shared subscriptions to composite destinations/virtual >> topics. >> *4)* We could add true native support for JMS 2.0 to the client (openwire) >> and server (treat shared subs/durables as their own thing in the broker >> logic and also in the different storage options) and this would take by far >> the most effort to do correctly. >> >> In my opinion number 3 seems the most viable if JMS 2.0 support is really >> desired as the level of effort wouldn't be as bad compared to trying to do >> full native support as described by number 4. Simply leveraging composite >> destinations behind the scenes seems like a decent solution on the server >> side as we should be able to get the desired behavior and spec compliant. >> >> Alright, all of that being said, while it would be kind of nice to have JMS >> 2.0 in 5.x to give people options, I still lean to the idea that it would >> be a better use of time to just work on improving the migration and feature >> parity of 5.x with Artemis instead of adding JMS 2.0 support as Artemis >> already supports it. If migration is easier and if all the main 5.x >> features people care about work in Artemis then people could just migrate >> to Artemis. >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
