Add support for Jakarta Servlet API Specification

[guadgarcia]

We are in the process of upgrading our Spring Boot application to use Spring Boot 3.0.1 and we are getting an error related to ESAPI. The issue is happening because ServletResponse is now located in a different package.

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Handler dispatch failed: java.lang.NoClassDefFoundError: javax/servlet/ServletResponse] with root cause","context":"","exception":"java.lang.ClassNotFoundException: javax.servlet.ServletResponse\n\tat java.base/java.net.URLClassLoader.findClass(Unknown Source)\n\tat java.base/java.lang.ClassLoader.loadClass(Unknown Source)\n\tat org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:149)\n\tat java.base/java.lang.ClassLoader.loadClass(Unknown Source)\n\tat java.base/java.lang.Class.forName0(Native Method)\n\tat java.base/java.lang.Class.forName(Unknown Source)\n\tat org.owasp.esapi.util.ObjFactory.loadClassByStringName(ObjFactory.java:158)\n\tat org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:81)\n\tat org.owasp.esapi.ESAPI.httpUtilities(ESAPI.java:123)\n\tat org.owasp.esapi.ESAPI.currentRequest(ESAPI.java:70)\n\tat

[xeno6696]

It's been a LONG TIME since I set up a Spring application, but IIRC the issue is that ESAPI codes against the servlet-api but it isn't packaged with it. I would first ensure that your application dependencies are explicit.

https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api

Some application servers have their own methods for supplying the servlet-api, I know with WebSphere we deployed it as a web app server library so applications didn't need to include it as their own dependency.

We Code against the specification only so there is no need for any explicit support for Jakarta, Websphere, etc. You supply your own implementation. It is 100% supported, you just need to fix your dependencies.

[guadgarcia]

Thanks for commenting back so quickly. Unfortunately the newest version of Spring and Spring Boot are using Jakarta Servlet API specification and no longer using Java Servlet API specification hence the new package for Jakarta's servlet api is starting with jakarta.servlet and not java.servlet. Also the newest versions of Tomcat and Jetty are now using this new Servlet API specification so I imagine other folks will be experiencing our pain soon.

[kwwall]

The issue is happening because ServletResponse is now located in a different package

@guadgarcia, it looks like jakarta.servlet-api changed this between their 4.x releases (when it was using javax.servlet.ServletResponse) and the 5.x version, when it was changed tojakarta.servlet.ServletResponse. That seems like a dubious move to me. Changing interfaces like this without several years of warning via deprecation seems like it would break a lot of code.

We have to support older versions of javax.servlet-api because many ESAPI clients are still running older versions of Java application servers and (at least originally) that was what the Glassfish reference model used as well as WebLogic server. And since it is the app server that generally decides that, maybe you need to switch to a different default app server. (I think you use an embedded version of Jetty, right?) That's the only thing I can think of beyond forking ESAPI and making those changes in your fork. (Come to think of it, the ServiceMix folks put an OSGI wrapper around ESAPI. Maybe you could get that to work? See https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.esapi.)

However, if you can come up with some other suggestion that will allow us to support clients using application servers that use javax.servlet-api as jakarta.servlet-api that doesn't require significant code changes to those ESAPI clients, I'm all ears and will gladly reopen this and we can consider working on something.

In the meantime, I'm going to convert this issue to a Discussion and hopefully get some more ESAPI community eyes on it.