cshannon commented on PR #969: URL: https://github.com/apache/activemq/pull/969#issuecomment-1430337307
So looking at this and thinking about it more I am seeing several problems including the fact that I realized this doesn't actually solve the problem for Spring boot compatibility. 1. This doesn't really make sense to introduce a new module like this into 5.17.x for a point/bug fix release as 5.17.x has already been out a while. Furthermore this only copies JMS 1.1 classes so is completely broken for most of the methods. This should be targeted for a future version. 2. In main/5.18.x there has been more JMS 2.0 work done so we should be using that as the baseline for this because it handles things properly like working between vendors. But there's still more work to be done because not everything is implemented. Any of the API methods that can be implemented now probably should be. I think most things besides shared subs can probably be done. 3. Anyone that uses the Jakarta API could reasonably assume that calling any method should work. Since there is no previous Jakarta messaging version before 3.0 any code that is Jakarta compatible could assume the spec should work so we would need to finish the implementation or at least be very clear in the documentation what won't work. 4. This doesn't actually fix the issue for Spring Boot 3 Spring Boot won't be able to add back in support because Spring boot is going to pull in the server itself to allow running the 5.x broker and the broker doesn't use the new Jakarta API. A new Jakarta client would only work if using just the client in the JVM and not the broker itself. For Spring 6.x I'm not sure, it may be good enough if it's just client support but if Spring 6 is calling off to any new methods that are not implemented in their messaging module (which they reasonably can do as I pointed out in number 3) then this breaks and won't work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
