is it possible (and if yes, how) to use the Universal Messaging as a JMS provider with the new jakarta classes? In Java 17, all javax.* classes have been renamed to jakarta.*.
We have a SpringBoot-2 based application that communicates with UM using the JMS API. Now we’d like to migrate the application to SpringBoot-3 and Java 17. And face the problem that SpringBoot uses jakarta classes whereas UM with its client side library uses the old javax classes.
You should be able to use nirvana library with no issues like you did previously. Nirvana API wasn’t completely backwords compatible before, it is now (according to documentation). But I would still recommend wrapping the the interface with IS services unless you need to use umserver internally. The problem with using a library is, it creates a huge dependency to the library. If you ever need to replace that API (during upgrade or replacing with some other product) each and every client needs to be updated. Sometimes it is impossible to find the clients especially if it has been a very long time since the implementation and even if you find them this simple change can be not so simple at all. Most upgrades fail before they start because of this.
I must have expressed myself not clearly. There are no IS services involved; this is a pure Java application communicating with the UM via JMS. If I were using the native UM API there would be probably no problem. But I use JMS and hence have one because the UM Impl still implements javax.* interfaces and not the jakarta.* ones.