Any plans for a version using Jakarta Servlet 5.0?

[mlemmens]

We are currently migrating our Spring Boot application to version 3.0.

In Spring Boot 3.0 they've migrated all dependencies from Java EE to Jakarta EE APIs. Now Jakarta EE 10 dependencies are used.

We are using the OWASP Java Encoder library and specifically the JSP module to encode user input. For example:

<%@ taglib prefix="e" uri="https://www.owasp.org/index.php/OWASP_Java_Encoder_Project" %>
<e:forHtml value="${user.name}" />

This is causing the following error:

java.lang.ClassNotFoundException: javax.servlet.jsp.tagext.SimpleTagSupport

This is because we are now using Jakarta Servlet 5.0 and the packages have been changed from javax.* to jakarta.*.
javax.servlet.jsp.tagext.SimpleTagSupport is now jakarta.servlet.jsp.tagext.SimpleTagSupport.

Are there any plans for a version using Jakarta Servlet 5.0?

I noticed that there's a discussion in the OWASP ESAPI project which deals with the same problem.

[jmanico]

We do not have direct plans to upgrade. Do you have any desire to submit a PR for this one? Regards, Jim @ Manicode

[xeno6696]

@jmanico don't sleep on this one. Long-term this means that the encoder project simply won't be used because the choice will be "go with new j2ee or use OWASP encoder?"

Accepting a PR would mean that you'd make a breaking decision for applications that haven't changed the namespace. This means either maintaining two branches of Encoder (one for javax and one for jakarta) or a forge-ahead breaking decision forcing all clients to upgrade to the jakarta namespace.

[casid]

@xeno6696 it's not as big I think, as only users of the encoder jsp module are affected. In theory this could be solved by copying the jsp module to something like jsp-jakarta and adjust all servlet dependencies to the new jakarta namespace. This would probably be easier to maintain than two different branches.

[kwwall]

@casid - It looks as though a simple grep of the code base shows that it affects all the encoder tags under 'jsp/src/main/java/org/owasp/encoder/tag' so that would be 19 files that they'd have to copy. Given how seldom the owasp-java-encoder needs to be updated, I think branching may actually be easier in this case... especially if they want to deprecate the current javax.servlet stuff and declare it EOL in a year or less. The downside of that is they'd have problems with the 'ESAPI Thunk' piece until ESAPI supports Jakarta (something we've been discussing here.)

@jmanico - would be nice of you to drop your thoughts on the ESAPI discussion that I referenced. Thanks.

[jeremylong]

We can add a Jakarta module, copy over the JSP and update appropriately.