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
