Switch from Tomcat/JAX-RS 2 to TomEE + CXF?

I've an old project that works just fine, running with RESTEasy on Tomcat 9. It's using the JAX-RS 2.0 API. But I'm under some pressure to migrate this to TomEE, CXF, and JAX-RS 3.

I think this means I'll have to trawl through all the imports changing javax... to jakarta... but is there much more to the conversion?

I should perhaps add that I do use the client API, but mostly restrict to fairly core/mainstream features of both client and server APIs.

I don't need a terribly specific description at this point, I really just need to get a feel on a scale of "nah, that's the bulk of it" to "nope, you're effectively going to have to rewrite everything"

Also, if the above is problematic, is it noticably simpler to take the project to TomEE and CXF but still using JAX-RS 2? (Or does that question not make sense, perhaps?)

Thanks for any guidance,
Toby
(And yes, I asked this on SO, with the usual unhelpful response!)

Sooo. They said you were an idiot for asking and besides there's already an answer for a scenario that almost, but not quite completely unlike what you have?

TomEE is Tomcat fortified with builtin JEE features. I've never felt the need for it - and doubly so since Spring Boot, but it does have its fans here.

The transition for Tomcat from javax to jakarta comes at Tomcat 10. So I'd recommend as a first step to do the jakarta upgrade. There are tools that can help with that, although in my case there was a little residual tweaking to do. Note that you may not only need to upgrade your source code, but also upgrade to Jakarta support libraries.

I think I did a CXF project several years ago. Somewhere around Tomcat 7, I believe and although it was new development, not a big problem.

CXF and JAX-RS are built into TomEE, so theoretically, if you can migrate to Tomcat 10, then mostly it should be a matter of pulling the external CZF and JAX-RS libraries from your WAR and deploying to TomEE 9.

Tim Holloway wrote:[...]TomEE is Tomcat fortified with builtin JEE features. [...]

Aha, you've seen SO too, eh? Actually in this case I just got a downvote with no comments whatsoever as to why!

But to the point, many thanks for your input, that's a good start.

Can you (or anyone) comment on whether the new API runs the old code, if one recompiles it with imports from jakarta... rather than javax, or does old stuff not work that way?

I actually have an SO account, but I haven't logged in or posted for many years.

SO is a great place to find stuff that's ready-to-run, but not so much on explanations. They've tried to become more friendly in recent times, but it comes hard to them.

If you're more interested in the theory behind the solutions (and our "be-nice" policy), the Ranch is a better bet.

Basically, Jakarta EE is JEE moved to the jakarta package tree, allowing for updates. So as a general rule, whatever logic you have that used a javax. class, interface or method will only require an edit to the imports statement. Since the essential parts of Java and JEE/Jakarta maintain a strong dedication to backwards compatability, you might see nome new methods or features in Jakarta, but virtually nothing deleted or broken.

Be aware, though that not every package in the original javax tree belonged to JEE, though, and the non-JEE packages still remain as "javax." You cannot simply brute-force edit all your imports en masse because of that. The conversion tool I used had a list of what it should change and what it shouldn't. It came up a little short on the JSF stuff, though. I don't thing they'd included the javax.faces package subtree in their list to convert.

The advantage of TomEE is that it comes with all kinds of libraries built in, JAX-RS amongst them. I've never seen a particular need for that, and just use plain Tomcat. Build system like Maven and Gradle make it easy to pull in external dependencies like JAX-RS, and Tomcat is much more widely used than TomEE, so in case of issues it's easier to find answers online.

I've also never seen a need for frameworks like RestEasy or CXF - I just use Jersey, the JAX-RS reference implementation. But maybe those other frameworks add some fantastic APIs on top of that; I don't know.

As Tim H said, migrating from javax to jakarta (and from Tomcat 9 to Tomcat 10) may require some adjustments in terms of which libraries to pull in, but you need to do that anyway at some point. In my experience, it was pretty much painless.

I haven't migrated to JAX-RS 3 yet, but I doubt that it involves much more than changing import statements and maybe some configuration settings.

The problem with Tomcat, versus using a full-fledged EE container like TomEE, is that it can get very difficult to get certain combinations of EE APIs to work together.

For instance, if you want to get JAX-RS to work in combination with CDI, you need a very specific set of dependencies and configuration to get it all to work well within Tomcat. In such a case, it might just be easier to use an application container that provides full EE support out of the box.

Note that if you use an EE container, you don't need CXF. If your application only relied on  standard JAX-RS and JAX-WS features, pulling CXF out should take only minimal effort.

JEE/Jakarta EE servers come in 2 varieties: partial-stack like Tomcat and Jetty and full-stack like TomEE, WebLogic, WebSphere. Wildfly and so forth. TomEE is, of course, all open-source, unlike the commercial products. Another open-source JEE full-stack server is JOnAS, produced by Group Bull and OW2. Mostly its audience is European.

The partial-stack servers support servlets, JSPs, JNDI and container-based authentication and authorization from the JEE standard. Full-stack servers include stuff like JMS, Web Services, Java ServerFaces, EJB/JPA and, well, a lot of other stuff. So much other stuff, in fact that a lot of Tomcat's initial popularity came from the fact that Tomcat can come up in seconds whereas a server like WildFly's predecessor JBoss sould take minutes to come online, slowing development down a lot. Initially, JBoss used an internal copy of Tomcat as its web page server subsystem, but they now have their own.

There is very little that a full-stack server can do that cannot be done in Tomcat, although a Tomcat webapp has to include JPA, JSF, etc. in libraries compiled into the WAR, whereas the full-stack servers don't, since they're compiled into the server. That is, in fact, what TomEE is: a Tomcat where the full stack features are compiled into a base Tomcat system to produce a full-stack server. Not actually as easy as it sounds, since when you move, say, your JSF application library from in-app to in-server it has to be very careful that two apps don't try to do conflicting things at the same time.

At this time, TomEE 9 claims to support 100% of the full JEE webapp server stack. A caveat to that is that it uses very specific versions of JEE support libraries. Probably the most notable case being that its EJB provider is Apache OpenStack and many people prefer Hibernate for that.

Correction. TomEE's JPA is OpenJPA. OpenStack is an entirely different animal.

Tim Holloway wrote:[...]
Basically, Jakarta EE is JEE moved to the jakarta package tree, allowing for updates. So as a general rule, whatever logic you have that used a javax. class, interface or method will only require an edit to the imports statement. Since the essential parts of Java and JEE/Jakarta maintain a strong dedication to backwards compatability, you might see nome new methods or features in Jakarta, but virtually nothing deleted or broken.
[...]

Perfect, huge thanks Tim, this is exactly what I was hoping to establish. It seemed like a simple question, but google as I might I couldn't seem to find anything to confirm it. I guess I'll go ahead and see if we can get this done. The project really only uses the JAX-RS stuff, so I think I'll have a decent chance using sed to do the translations. Fingers are crossed.

And thanks Stephan too for the additional context

(And I'm glad to hear I'm not the only one who finds SO to be ... much less than it could be. I don't use it often, and I seem to be disappointed every time. Then I get smart and come back here and find good things!)