When i try to upgrade an application to spring boot 2.4.13 and deploy to websphere 8.5.5 it gives me below error.java.lang.NoSuchMethodError: javax/servlet/http/HttpServletResponse.setContentLengthLong(J)V (loaded from file:/apps/WebSphere85/AppServer/ plugins/javax.j2ee.servlet.jar by org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@ede7c06f) called from class org.springframework.http.server.ServletServerHttpResponse (loaded from file:/applis/196233/was/app_name/installedApps/ app.ear/app-war.war/WEB-INF/lib/spring-web-5.3.20.jar by

I force pushed the servlet 3.1.0 in pom.xml to avoid it using from parent class loader. still it is always taking jar from parent class loader.

 <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.1.0</version>
        </dependency>

It is working with earlier version of spring boot 2.1.3.RELEASE. we were not suppose to upgrade the servlet to 3.1.0 in server as it is used by different applications. please advice

CodePudding user response：

This is not a workable scenario. While you can override many of the server-provided APIs in an application running on a WebSphere server, Servlet is not one of them - the web container must link to the version of the API within the server, and there's no way for an application to separately use that API without class conflict issues. If you hadn't hit a NoSuchMethodError, you'd instead run into a ClassCastException when the web container attempts to cast your application's Servlet class to the internal instance of the API.

WebSphere 9 supports Java EE 7 (including Servlet 3.1), and Liberty supports versions all the way up to the latest Jakarta EE specs, so if moving to a newer server version is possible, that would work. If you're locked to 8.5.5, though, you'll have to stick with a version of Spring that supports Servlet 3.0 at the latest.