[Discussion] Supporting Jakarta EE 9+ Servlet API

[bwolff]

Issue created to continue the discussion started in the RAP forum/newsgroup: https://www.eclipse.org/forums/index.php/t/1111838/

The goal is to discuss options and plans to support, or migrate to the new Jakarta EE 9+ (Jakarta Servlet 5.0+) jakarta.servlet API (and possibly others).

[bwolff]

To answer on the last post from @mknauer here: https://www.eclipse.org/forums/index.php?t=msg&th=1111838&goto=1855689&#msg_1855689

I agree, such a move would involve a lot of work and coordination with other projects. Thanks for the insights from the Eclipse platform people. It would also be interesting to learn from other Eclipse projects that rely more heavily on the "legacy EE" APIs.

Imho, the "legacy" Java EE APIs will probably become the new Java 8 ;). They will live on and will be supported for many years to come. In the RAP/RWT context, I see the risk to navigate into a "dead-end", or at least be restricted from using it together with Tomcat 10+ and Jetty 11+, thus restricting usage in more and more scenarios in the long-term.

Regarding a compatibility layer that would require no code changes: I'm not an IT lawyer, but I guess that won't be possible due to legal restrictions on using the javax.servlet namespace, which was the reason for the change to jakarta.servet in the first place ;).

In any case, I'm happy to continuing the discussion here :).

[ifurnadjiev]

I want to share something about Jakarta EE 9 support in RAP. I've tested one tool provided by Apache Tomcat [1, 2] (Apache Tomcat migration tool for Jakarta EE) with the latest RAP release. There are actually minor problems to convert a war file (RAP app) based on javax namespace to jakarta namespace. I've opened an issues against Equinox [3] and Tomcat [4]. In general, you can use this tool to make RAP application compatible with Jakarta EE 9. The simplest way is to drop the war file not in Tomcat 10 "webapps" folder, but in "webapps-javaee" and the migration tool will do the job automatically.

I hope that the blocking issue will be fixed soon.

[1] https://tomcat.apache.org/download-migration.cgi [2] https://github.com/apache/tomcat-jakartaee-migration [3] https://github.com/eclipse-equinox/equinox/pull/164 [4] https://github.com/apache/tomcat-jakartaee-migration/issues/39

[bwolff]

Thanks a lot for sharing your efforts @ifurnadjiev!

From what I understand, the migration tool takes a fully built artefact (WAR file) and converts it ad-hoc from "javax." to "jakarta." namespace. At least that will allow to deploy RAP apps on Tomcat 10+ (not taking into considerations any deprecations in the Jakarta EE APIs in the future).

This leaves the "issue" that you still have to write the code against the javax APIs. However, since RAP is part of Eclipse, we should probably just wait until the Eclipse platform moves to the jakarta APIs. I cannot imagine that this will take very long, but let's see.

In the meantime, the most pragmatic approach for my use-case (using RWT standalone in a non-osgi environment along with other jakarta-based dependencies) would be to fork the RAP sources and migrate the required bundles to the jakarta API at the source level. That should at least unblock me until the Eclipse platform moves to jakarta.

[ifurnadjiev]

@bwolff Sure. That's only a temporary solution for those, needed RAP running on Jakarta EE 9 immediately.

[SteffGo]

I would like to point out that at the moment, it's not possible to create a Eclipse RAP application as spring boot V3 application. Starting with version 3.0, spring boot is using jakarta.* instead of javax.*.

[theanuradha]

Spring Boot V3 migration blocking due to using jakarta.* instead of javax.*.

[TheLawful]

We too have a complex RAP application as the final blocker at migration of our platform to Jakarta. The migration tool works surprisingly well on Windows (a lengthy error log dealing with jakarta.servlet-api is written to /work/ but it works anyway), but leads to a complete mess on Linux, with classloader issues and version parsing conflicts of all kinds, using Tomcat 10.1.11 and exactly the same app. After several days of frustrating experiments, going down to Equinox and finally, OSGI HttpService, I'm losing my hope we could get it running at all. Some of the comments concerning Jakarta EE on the Equinox project* pointing at the outdated OSGI specifications which obviously dictate javax.*, Servlet API 2.1 and all don't leave me with much hope. My current estimate is that the Eclipse platform will never be migrated to Jakarta, even if Eclipse Foundation is the maintainer of that standard. Bummer. Nice job, Oracle, you killed RAP. Or what are the options?

*https://github.com/eclipse-equinox/equinox/issues/183, follow the links there. https://github.com/osgi/osgi/issues/551

[jensborrmann]

The next external factor that seems to complicate things is the evolution of the JakartaEE APIs.

Especially the servlet API has some (minor) breaking changes in JakartaEE 10. This compromises/destroys the ability to work on the bytecode via transformations.

We haven't checked yet if this has become a showstopper yet. But it's obvious that without a real migration of the Eclipse platform, this won't work one day.

[mknauer]

Some updates...

• With our last release RAP 3.26 in September we tried to achieve Jakarta Servlet 6.0 compatibility by removing deprecated API, returning null and empty collections in other cases. However, there is one area for which we have not yet found a solution in HttpSessionWrapper:

  @Override
  @Deprecated  
  public HttpSessionContext getSessionContext() ...
  

  Our problem: For the currently supported servlet version we have to keep the method like this thanks to @Override, on the other hand the HttpSessionContext class has been removed in the newer servlet version. We are certainly open to any suggestions and ideas to solve that.
• The Eclipse Platform Team is working on an upgrade to to Eclipse Jetty 12 for their next release in December. This move allowed us to migrate to the same version, which is what we did with our RAP M2 milestone. This doesn't change the supported servlet version yet, but we hope to have a better chance to migrate in the future.

[fappel]

Hm, it's been quite a while, so I'm not sure about what the purpose of this wrapper is. As far as I can see, it delegates every method except the getServletContext method more or less to the wrapped session. Unfortunately, I failed to comment if or why this is important. Might as well be because of a container bug that has been fixed in the last decade or so. Anyway, it might be worthwhile to try to delete the HttpSessionWrapper and use request.getSession() directly in the CutOffContextPathWrapper.RequestWrapper. Without the class the problem would vanish, right? Greetings Frank

[ifurnadjiev]

The HttpSessionWrapper is used in order to provide another "wrapper" - org.eclipse.rap.rwt.osgi.internal.ServletContextWrapper. @fappel Do you remember what is the idea behind ServletContextWrapper and the inner attributes map?

[fappel]

Looking at the lines 183-190, the method setAttribute, it seems as if the context#setAttribute call might not actually sets the given name/object pair reliable. Otherwise the condition in line 196 would always be false and line 187 would never be called. Likewise, setting the resource root location in the constructor could be done on the context directly. Similar suspicion at line 155. I can see now why this approach enforces the need for the session wrapper. It might be that there were some "lifecycle issues" with the underlying ServletContext of some containers such that the attribute map would not accept attributes before some internal initialisations took place. While writing this I had the idea to look at the corresponding test case and tada:

line 256: ////////////////////////////////////////////////////////////////////////////////////////////////// // START ATTRIBUTE BEHAVIOR TEST // // Note [fappel]: This fixes a problem with underlying OSGi ServletContext implementations // that do not implement the attributes API part.

So, there has been a reason for using the inner attribute map. But maybe the underlying containers have improved and this approach is obsolete?

[ifurnadjiev]

RAP 4.0 supports Jakarta EE10 and Servlet API 6.

[bwolff]

That's awesome, thanks a lot for the great work and making this possible! I'm looking forward to running RWT on the latest Spring Boot 3.x stack 😃. Good to see RAP/RWT on JakartaEE. A very long-term reliable product has become even more long-termy ;).