/WEB-INF/JSPs/projectmt/formprojectlaunching. jsp (677,22) pwc6228 :#{...} Not allowed in a templa

When using the jetty plug-in (6.1.9) for debugging, we found that accessing #{...} When the expression page (the template expression is used on the page), the following exception is thrown: Java code

1. Org. Apache. Jasper. jasperexception:/WEB-INF/JSPs/projectmt/formprojectlaunching. jsp (677,22) pwc6228: # {...} not allowed in a template text body.
   
2. At org. Apache. Jasper. compiler. defaulterrorhandler. jsperror (defaulterrorhandler. Java: 62)
3. At org. Apache. Jasper. compiler. errordispatcher. Dispatch (errordispatcher. Java: 357)
4. At org. Apache. Jasper. compiler. errordispatcher. jsperror (errordispatcher. Java: 169)
5. At org. Apache. Jasper. compiler. validator $ validatevisitor. Visit (validator. Java: 731)
6. At org. Apache. Jasper. compiler. node $ elexpression. Accept (node. Java: 929)
7. At org. Apache. Jasper. compiler. node $ node. Visit (node. Java: 2257)
8. At org. Apache. Jasper. compiler. node $ visitor. visitbody (node. Java: 2307)
9. ...

Org. apache. jasper. jasperexception: // WEB-INF/JSPs/projectmt/formprojectlaunching. JSP (677,22) pwc6228 :#{...} not allowed in a template text body. at Org. apache. jasper. compiler. defaulterrorhandler. jsperror (defaulterrorhandler. java: 62) at Org. apache. jasper. compiler. errordispatcher. dispatch (errordispatcher. java: 357) at Org. apache. jasper. compiler. errordispatcher. jsperror (errordispatcher. java: 169) at Org. apache. jasper. compiler. validator $ validatevisitor. visit (validator. java: 731) at Org. apache. jasper. compiler. node $ elexpression. accept (node. java: 929) at Org. apache. jasper. compiler. node $ nodes. visit (node. java: 2257) at Org. apache. jasper. compiler. node $ visitor. visitbody (node. java: 2307 )...

This exception is not found when the project is packaged and deployed to Tomcat (5.5.

Based on the above exception information, after some network searches, it is found that the original jsp2.1 specification pair #{...} Compatibility problem: reference prior to JSP 2.1, the # {} syntax was not reserved. therefore, there might exist JSP pages based on earlier versions of JSP technology that use the # {characters where they are not allowed, according to the JSP 2.1 specification. these pages, when used in
JSP 2.1 application, will generate a translation error.

In fact,
1. Before jsp2.1, the JSP compiler did not parse the # {} expression (not a reserved expression), because in the previous JSP, the El expression was represented by $;
2. Because # {} is not a reserved expression in JSP, the El expression is represented by # {} In JSF;
3. In struts2, ognl (Object-graph Navigation language, a powerful expression language) is also represented;
4. in the jsp2.1 specification, Sun aims to unify the El expression syntax of JSP and JSF, # {} is used as a reserved expression (Sun claims that JSF's managedbean can also be directly referenced in pure JSP). That is to say, the server that uses the jsp2.1 specification will automatically compile the # {} expression;

5. jetty6 and tomcat6 adopt the jsp2.1 specification, while jetty5 and tomcat5 adopt the jsp2.0 specification.

OK, the problem seems clear. Using jetty5 and tomcat5 will not cause this JSP compilation error. So what if we need to use jetty6 or tomcat6?

In servers using the jsp2.1 specification (such as jetty6 and tomcat6), we have two solutions to solve the compatibility problem of this El expression:
Solution 1: Add the following configuration in Web. xml of a web project:

<JSP-property-group>

1. <URL-pattern> *. jsp </url-pattern>
2. <Deferred-syntax-allowed-as-literal>True</Deferred-syntax-allowed-as-literal>
3. </JSP-property-group>

<JSP-property-group> <URL-pattern> *. JSP </url-pattern> <deferred-syntax-allowed-as-literal> true </deferred-syntax-allowed-as-literal> </JSP-property-group>

This requires the servlet2.5 specification, so you must also modify the web-app node configuration to: Java code

1. <Web-app id = "ksoa3" version = "2.5" xmlns = "http://java.sun.com/xml/ns/j2ee" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
2. Xsi: schemalocation = "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd">

<Web-app id = "ksoa3" version = "2.5" xmlns = "http://java.sun.com/xml/ns/j2ee" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: schemalocation = "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd">

Solution 2: Add deferredsyntaxallowedasliteral = "true": <% @ page contenttype = "text/html; charset = UTF-8 "deferredsyntaxallowedasliteral =" true "%>

<% @ Page contenttype = "text/html; charset = UTF-8" deferredsyntaxallowedasliteral = "true" %>

Because solution 1 only needs to modify one configuration, and the maintenance cost is low, it is recommended to use solution 1.

After the above solution is used, everything runs normally on servers that adopt the jsp2.1 specification. However, because servers using the jsp2.0 specification (such as Tomcat 5 or jetty5) cannot identify the above configuration information, if these configurations are also used on servers using the jsp2.0 specification, the results will be very serious:

1. The $ {} expression in the JSP page will not be compiled
2. the JSP page rendering with the # {} expression is unsuccessful.

So far, jsp2.1 is not applicable and compatible with jsp2.0 configurations. Therefore, you can only configure jsp2.1 Based on the JSP standard version used by the server.