Network Deployment (Distributed operating systems), v8.0 > Reference > Developer best practices
JSP migration best practices and considerations
The standard JSP tags from JSP 1.1 such as jsp:include, jsp:useBean, and <%@ page %>, migrate successfully to JSP 2.0. However, there are several areas that must be considered when migrating JSP. This topic discusses the areas that consider when migrating JSP.
Classes from the unnamed or default package
As of JSP 2.0, referring to any classes from the unnamed or default package is not allowed. This can result in a translation error on some containers, specifically those that run in a JDK 1.4 or greater environment which also breaks compatibility with some older JSP applications. However, as of JDK 1.4, importing classes from the unnamed package is not valid. Refer to the Java 2 Platform Compatibility with Previous Releases web site for details. Therefore, for forwards compatibility, applications must not rely on the unnamed package. This restriction also applies for all other cases where classes are referenced, such as when specifying the class name for a tag in a Tag Library Descriptor (TLD) file.
Page encoding for JSP documents
There have been noticeable differences in internationalization behavior on some containers as a result of ambiguity in the JSP 1.2 specification. However, steps were taken to minimize the impact on backwards compatibility and overall, the internationalization abilities of JSP files have been greatly improved.
In JSP specification versions before JSP 2.0, JSP pages in XML syntax, JSP documents, and those in standard syntax determined their page encoding in the same fashion, by examining the pageEncoding or contentType attributes of their page directive, defaulting to ISO-8859-1 if neither was present.
As of JSP 2.0, the page encoding for JSP documents is determined as described in section 4.3.3 and appendix F.1 of the XML specification, and the pageEncoding attribute of those pages is only checked to make sure that it is consistent with the page encoding determined as per the XML specification. As a result of this change, JSP documents that rely on their page encoding to be determined from their pageEncoding attribute are no longer decoded correctly. These JSP documents must be changed to include an appropriate XML encoding declaration.
Additionally, in JSP 1.2, page encodings are determined on translation unit basis whereas in JSP 2.0, page encodings are determined based on each file. Therefore, if the a.jsp file statically includes the b.jsp file, and a page encoding is specified in the a.jsp file but not in the b.jsp file, in JSP 1.2 the encoding for the a.jsp file is used for the b.jsp file, but in JSP 2.0, the default encoding is used for the b.jsp file.
web.xml file version
The JSP container uses the version of the web.xml file to determine whether you are running a JSP 1.2 application or a JSP 2.0 application. Various features can behave differently depending on the version of the web.xml file. The following is a list of items that JSP developers should be aware of when upgrading their web.xml file from version Servlet 2.3 to version Servlet 2.4:
- EL expressions are ignored by default in JSP 1.2 applications. When you upgrade a web application to JSP 2.0, EL expressions are interpreted by default. We can use the escape sequence, \$, to escape EL expressions that should not be interpreted by the container. Alternatively, you can use the isELIgnored page directive attribute, or the <el-ignored> configuration element to deactivate EL for entire translation units. Users of JSTL 1.0 must upgrade their taglib imports to the JSTL 1.1 URI or use the _rt versions of the tags, for example, use c_rt instead of c, or fmt_rt instead of fmt.
- Web applications that contain files with an extension of .jspx will have those files interpreted as JSP documents, by default. We can use the JSP configuration element <is-xml> to treat .jspx files as regular JSP pages, but there is no way to disassociate .jspx from the JSP container.
- The escape sequence \$ was not reserved in JSP 1.2. The output for any template text or attribute value that displays as \$ in JSP 1.2 was \$, however, the output now is just $.
jsp:useBean tag
WAS enforces more strict adherence to the specification for the jsp:useBean tag: with type and class attributes. Specifically, you should use the type attribute to specify a Java type that cannot be instantiated as JavaBeans. For example, a Java type that is an abstract class, interface, or a class with no public no-args constructor. If the class attribute is used for a Java type that cannot be instantiated as JavaBeans, the JSP container produces an unrecoverable translation error at translation time.
Generated packages for JSP classes
Any reliance on generated packages for JSP classes results in non-portable JSP files. Packages for generated classes are implementation-specific and therefore do not rely on these packages.
JspServlet class
JspServlet classes are no longer used. Any reliance on the existence of a JspServlet class causes unrecoverable error problems.
While the JSP classes migrate successfully, if you are precompiling JSP classes, precompile them again on the target server level. Annotation processing is supported as of JSP 2.1. Recompile the JSP classes to take advantage of this processing.
JSP
Migrate web application components from WAS v5.x
http://java.sun.com/j2se/1.4/compatibility.html#source