I think it's fine to do a PR for your client side changes as a first step (I will review it as well) as long as we are clear on what is and isn't supported. We just need to be careful and not advertise "JMS 2.0" support when that's not true and instead specify exactly what is and isn't supported as part of the Jira and commit.
I will say that I'm not sure if it's a good idea to do any JMS 2.0 support (even basic client changes) in a 5.16.x release the more I think about it as there will be a new dependency on JMS 2.0 jar and a dependency change like that would be very un-expected in a point/bug fix release. It may make sense to just move it to 5.17.0 and get it out faster, there's nothing that says we can't do 5.17.0 within a couple months vs the 2 years or whatever 5.16 took. On Thu, Jun 25, 2020 at 10: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 >
