There are many hints through the web suggesting that the version in web.xml, <web-app version="xxx"> must match the current API used (and expected) by the corresponding application. E.g.:
But I have failed to prove it. Does this version has any effect when compiling the JSPs?
I've been debugging a [...] JasperException: somewhere.jsp(69,10) The function concat must be used with a prefix when a default namespace is not specified in a Tomcat 6.0.45.
After some research, I found that the somewhere.jsp invokes a bean method with arguments, something only support in EL 2.2+ (see for example Differences between EL 2.1 and 2.2). So far so good: Tomcat 6.0.45 is a servlet 2.5 container that only supports EL 2.1.
But I then installed the same app on a Tomcat 8.0.32 (Servlet 3.1, EL 3.0), and with the same web.xml, the failure doesn't display, something that surprises me, because in the web.xml, I have version="2.4".
I have also failed with further attempts to tweak the Servlet API version used to compile and run the JSPs by only changing this version attribute, so I'm quite puzzled.
The version specified in web.xml only determines the rules that are used to parse the web.xml file. The behaviour of the container is always determined by the version of the specifications it implements.
For example, you can't disable annotation scanning (introduced in Servlet 3.0 / Tomcat 7) by specifying version="2.5" in the web.xml. See section 1.6.2 of the Servlet 3.0 servlet specification for an example of this requirement.