MockServletContext hardcoded to return 2.5 for servlet version [SPR-6194]

[spring-projects-issues]

Bob Jacoby opened SPR-6194 and commented

MockServletContext is hardcoded to return '5' for the servlet minor version.

org.springframework.web.context.ContextLoader contains a check of the servlet version number to determine whether or not to call a servlet 2.5 API method.

// Assign the best possible id value.
if (servletContext.getMajorVersion() > 2 || servletContext.getMinorVersion() >= 5) {
     // Servlet 2.5's getContextPath available!
     wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX + servletContext.getContextPath());
}

Since MockServletContext will return 2.5 as the servlet version, our 2.4 servlet api test code throws a runtime exception when the ContextLoader attempt to call the 2.5 API method.

Could setters be provided for the major/minor version numbers in MockServletContext? The 2.5 method getContextPath could also throw an exception if called when the mock context is set to 2.4.

I consider this a bug as I thought it was supposed to be able to be used in a 2.4 environment. If not, I guess this is a enhancement/improvement. :)

---

Affects: 3.0 RC1

Referenced from: commits 9a111e5

[spring-projects-issues]

Juergen Hoeller commented

We generally don't support older Servlet API versions for mocking... We rather always expose the latest and expect your test code to continue working when a newer Servlet API version is in use. If you're combining this with custom mocks, this could indeed be a problem. However, I don't quite understand why you're using MockServletContext and then have test code that fails when calling getContextPath on that very MockServletContext?

Juergen

[spring-projects-issues]

Bob Jacoby commented

"However, I don't quite understand why you're using MockServletContext and then have test code that fails when calling getContextPath on that very MockServletContext?"

I don't think I explained my use case very well. It's not my test code that's calling the 2.5 method and causing the problem. It's a spring class that was written to support both 2.4 and 2.5 environments.

I have an integration test where I want to initialize the spring web application context. To do so I use a MockServletContext which I then pass to the spring class org.springframework.web.context.ContextLoader (initWebApplicationContext method) to load the context. The signature of ContextLoader's initWebApplicationContext contains a ServletContext argument. So the methods called on the servletContext instance passed into the the ContextLoader are limited to those defined by the ServletContext interface.

In order to support both servlet 2.4 and 2.5 environments, the ContextLoader's initWebApplicationContext queries the instance of the servletContext passed to it to determine which servlet api is "available". Since the MockServletContext is hardcoded to return 2.5, ContextLoader determines that the servlet environment is 2.5, which is incorrect in my case (a 2.4 environment). The ContextLoader will then attempt to call a 2.5 api method, which causes a method not found exception since the 2.4 interface does not have that method. If I could set the MockServletContext to return 2.4, ContextLoader would not try to call the 2.5 method and everything would be happy.

In short, the current MockServletContext appears to only be useful in a servlet 2.5+ environment if used to initialize the spring context.

[spring-projects-issues]

Costin Leau commented

Bob, I've added a setMinorvVersion() to the MockServletContext which allows one to specify an integer between 3 and 5. There are no additional checks for the methods invoked.
I was tempted to add automatic Servlet version detection but that might have caused issues when executing tests with different servlet versions in the classpath.

It would be great if you could take the latest trunk for a spin and let us know if the current fix solves your problem.