Table of Contents
This chapter describes the concepts, functions, and configurations of the JSP engine.
The JSP engine is embedded in web engines. It exists in each web context. This section does not explain JSP standards. Refer to the JSP standards for more information about creating a JSP engine.
When web clients request JSP pages, the JSP engine finds the pages and converts them to servlets. During the servlets conversion process, the engine creates Java files and SMAP files, and compiles the Java files to create class files that will be used for the services.
If JSP pre-compilation is not used, JSP files are compiled the first time the request is received, so when the first request happens, the response might take more time because the access to the OS file system occurs frequently.
In an environment where network-attached storage (NAS) is used, if there are many files that require compilation because of tags and JSP include relations, many requests will be sent to the NAS, which delays the response. Depending on the NAS driver operation, a JSP file with a size of 0 might be read without generating a java.io.IOException. Jasper reads files using the JVM file I/O API, so parsing of the JSP file will fail.
JSP in the Web Context
The JSP file exists under the root of the web context. It can be packaged by creating a separate directory, and can be packaged under the META-INF/resources/ directory defined from Servlet 3.0 onward.
The JSP file can be found even if there is a META-INF/resources/ directory in the *.jar library files under WEB-INF/lib/. However, the JSP files under the WEB-INF directory are not serviced. Due to security reasons, the web client cannot access the files under WEB-INF/. For more information about the internal structure of the web context, refer to "3.2.2. Web Context Structure (WAR File Structure)".
Note
For more information about META-INF/resources/, refer to the resource-related API description of http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html.
[Attention]
Internal testing shows that the javac library that is provided by the Oracle JDK is not thread-safe, so the property jeus.servlet.jsp.compile-java-source-concurrently is provided and the default value is false. When the request threads compile .java files, they set a lock at the JVM scope.
If the javac library provided by the JDK is thread-safe, the property jeus.servlet.jsp.compile-java-source-concurrently can be set to "true" in jeus-web-dd.xml as follows. If so, verify that the JSP files compile normally in a multi-threaded environment.
<properties>
<property>
<key>jeus.servlet.jsp.compile-java-source-concurrently</key>
<value>true</value>
</property>
</properties>
JEUS has always included Jasper, the Tomcat JSP parser, but changed the package name and included it in jeus.jar. JEUS 8 uses the Tomcat 8 based Jasper, and the package is named org.apache.jasper, but it is packaged as a separate library jasper.jar. The library is located in the following path:
$JEUS_HOME/lib/system/jasper.jar
When using Jasper, consider the following:
-
The jasper.jar library is modified for JEUS, so it must not be overwritten with the Tomcat library. If it is, the server will not start.
-
When an application uses Tomcat's jasper.jar in WEB-INF/lib, the <webinf-first> option in jeus-web-dd.xml must be set to 'true'. Otherwise, the jasper.jar classes from JEUS will be used, which can cause unpredictable results.
Differences Between Tomcat Jasper and JEUS Jasper
As explained above, JEUS modifies parts of the version of Jasper that are provided by Tomcat, so consider the following:
-
JEUS provides functions including in-memory JSP complication, which Tomcat Jsaper does not provide.
-
JEUS does not use the tag handler pool or the page context pool.
64KB Method Size Limitation when Compiling Java Source
If there is too much content in a single .jsp file when creating JSP, the size of a method in the file may exceed 64KB. In this case, the .java file cannot be compiled by a Java compiler because it violates the Java Language Standards.
The 64KB limit can be avoided if most of the content is in the string format, such as SQL statements or HTML tags. Configure the web.xml file as follows:
<servlet>
<servlet-name>jeus.servlet.servlets.JspServlet</servlet-name>
<servlet-class>jeus.servlet.servlets.JspServlet</servlet-class>
<init-param>
<param-name>genStringAsCharArray</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>jeus.servlet.servlets.JspServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
If a file with too many Java codes fails to be compiled, separate responses using the <jsp:include> element. The following is an example of using the <jsp:include> element.
<body>
Template Page<br/>
<jsp:include page="module_one.jsp" />
<jsp:include page="module_two.jsp" />
</body>
The JSP engine provides graceful reloading, precompiling, as well as JSP compiling and running at the memory.
JSP files are usually used for views rather than for logic, so users often want to change the JSP files while still running the service, so web applications that use JSP are often deployed as a directory instead of a WAR.
-
When deployed as a directory
If a JSP file is changed in the directory where the application is deployed as a directory, the JSP engine compares the last modified date of the existing compiled class files with the modified date of the original files, and then compiles the files.
When this happens, if the configuration <check-included-jspfile> is 'true', even if the requested JSP file has not changed, the JSP files or tag files (.tld) that are included in the JSP file will be checked to recompile the JSP file.
The JSP engine supports graceful reloading. Therefore, even if recompilation occurs from changing the JSP file, then continuous service can be supported with the existing compilation.
-
When deployed as a WAR
If applications are deployed in WAR, all of the files will be repackaged to be redeployed, so the risk is high in the perspective of service operation.
If a large amount of files are changed, consider graceful redeployment, which is provided Starting from JEUS 7. For more information about graceful redeployment, refer to "3.3.2. Web Context Deployment (Graceful Redeployment)".
Note
When a native library is loaded through System.LoadLibrary() method within the JSP file, JSP reloading may fail.
To reload the JSP, a class loader must be created per JSP and the class loader must be replaced when reloading. The references for the native library is managed by the JVM in the class loader. When the class loader instance goes through the garbage collection, the reference gets cleaned up. Thus, if the JVM GC does not occur when the JSP class loader needs to be replaced, JSP reloading will fail. Since the JVM GC cannot be controlled from JEUS and this issue occurs due to the internal structure of the JVM, it cannot be resolved.
Therefore, it is recommended to load a native library only once at server startup. When a native library is modified, JEUS cannot guarantee a successful reloading of the library within the JVM.
JSP precompilation compiles JSP pages of a web context in advance. This can be done using the appcompiler script or the precompile-jsp (jspc) command in jeusadmin.
The appcompiler can precompile JSP files even in an offline state and precompile-jsp can precompile the modules that are deployed on JEUS. Precompilation can help improves performance when the JSP is called for the first time.
For more information about appcompiler or the precompile-jsp command in the console tool, refer to JEUS Reference Book. "4.3. appcompiler" and JEUS Reference Book. "4.2.8.21. precompile-jsp" respectively.
When multiple web engines execute a service using the same source file from NAS, a delayed service or errors can occur due to OS file system access operations that are needed at JSP compilation time. In order to address this issue, the JSP precompilation and JSP graceful reloading functions are provided, but a more fundamental resolution of compiling and executing in memory is also provided.
The JSP engine saves the .java and .class files, the results of JSP compilation, in memory. Therefore, the engine does not access the file system except for when reading metadata and content from the .jsp file. This reduces the number of file accesses, and thereby reducing any service delays that can occur at JSP compilation time.
The .java and .class files are actually needed for other reasons. They are used in the file system by using a background thread that every JSP engine has, instead of using a request processing thread. Since the thread handles requests in the order they are received, the chances of bottlenecks happening in the file system due to file I/O requests are low, but the .smap files are not used. The previous JSP compilation method should be used if the .smap files need to be used.
The JSP engine uses the in-memory compilation method by default. To use the previous method, configure it in jeus-web-dd.xml. For detailed information, refer to "4.4.2. Configuring jeus-web-dd.xml".
The JSP engine can be configured in WebAdmin or in each application's jeus-web-dd.xml file.
The JSP engine of a web engine can be configured in WebAdmin.
-
Click [Servers] from the left menu to go to the list of servers. Click a server from the list to go to the server configuration page. From the page, go to the [Engine] > [Web Engine] > [Jsp Engine] tab.
-
Click [Lock & Edit] to change to configuration mode.
-
Configure the basic information on the Jsp Engine page and click [OK].
The following describes each item.
Item Description Jsp Work Dir Root directory where Java source files created by JSP are saved.
The files are not directly created in the root directory. Directories are created using the domain name, server name, and web application name. The files are created in these directories. In other words, class files are not shared by different web engines.
If 'Compile Output Dir' is not set, class files are created in the same path. By default, the class files are created in the following location:
-
EAR application
INTERNALGENERATED_HOME/ear1/web1/__jsp_work
-
Standalone web module
INTERNALGENERATED_HOME/web1/__jsp_work
Java Compiler Command that executes the Java compiler that compiles JSP Java source to servlet classes. Since the default value is the most efficient, it is not recommended to change this setting.
Compile Output Dir Location of the class files that are created by compiling the Java files, which were created by the JSP parser. The class files are used to execute the services. If not set, they are created in the same directory as the Java files.
Compile Option Servlet compiler Compile Encoding Encoding option used to compile the servlet source files created by parsing JSP files. This encoding is used as an encoding option for a Java compiler.
From JEUS 8, this encoding is no longer referenced, and JSP page encoding is used.
Check Included Jspfile The JSP engine checks whether a requested JSP page has been modified. As well, it checks whether all JSP files and tag files that are included with the <%@ include file=”xxx.jsp” %> directive are modifed and then performs compilation. If set to 'false', then only checks whether the requested JSP page has been modified and then performs compilation.
Keep Generated Option to keep the Java and SMAP files created by the JSP parser. This is useful for debugging. If set to 'false', files will be deleted after being created. For performance reasons, it is not recommended to change this setting. Graceful Jsp Reloading Period Sets the period in which Graceful Jsp Reloading is run in units of ms.
Use In Memory Compilation Function used to create, compile, and execute .java and .class files when JSP files that are running need to be recompiled. Refer to "4.3.3. JSP Compilation and Execution in Memory" for detailed information. -
-
After completing the configurations, click [Apply Changes] to apply the changes. The following result is displayed.
The JSP engine can be configured in jeus-web-dd.xml.
[Example 4.1] Web Context Configuration File: <<jeus-web-dd.xml>>
<jeus-web-dd xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="7.0">
<enable-jsp>true</enable-jsp>
<jsp-engine>
<jsp-work-dir>/home/user1/myjspwork/</jsp-work-dir>
<java-compiler>java6</java-compiler>
<compile-option>-g:none –verbose</compile-option>
<compile-encoding>UTF-8</compile-encoding>
<check-included-jspfile>true</check-included-jspfile>
<keep-generated>true</keep-generated>
<use-in-memory-compilation>true</use-in-memory-compilation>
</jsp-engine>
</jeus-web-dd>
The following describes each configuration tag.
| Tag | Description |
|---|---|
| <enable-jsp> | Option to use JSP. JSP file is executed through the default JEUS servlet. |
| <jsp-engine> | Settings for JSP pages that belong to the web context. This element is the same as the JSP engine setting in WebAdmin. If the JSP engine is configured in domain.xml, this setting has a higher priority. For more information about configuring the JSP engine in WebAdmin, refer to "4.4.1. Configuring at the Web Engine Level". |
In JEUS 4 and 5, non-standard functions are provided for applications that were developed before servlet 2.3, and the syntax does not conform to the JSP syntax. Starting from JEUS 6, syntax checking is more strict and the JSP parser has been replaced with a Jasper-based JSP parser to support JSP 2.1, but the existing JSP parser is also supported for backward compatibility with existing JSP.
Errors may occur when deploying web modules that ran successfully in JEUS 4 and 5. To use the current specifications such as JSP 2.1, check the error messages that are generated when compiling the JSP, and modify the module accordingly.
To use the existing modules without using the current specifications, add the following configurations to jeus-web-dd.xml. This will allow using the JSP parser, which is compatible with JEUS 4 and 5, in the web context.
[Example 4.2] Web Context Options for JSP Backward Compatibility: <<jeus-web-dd.xml>>
<properties>
<property>
<key>jeus.servlet.jsp.modern</key>
<value>false</value>
</property>
</properties>
The options in jeus-web-dd.xml are applied to the web context, but it is also possible to apply them to the web engine or the virtual host. To apply the options at the engine level, set the following VM option. Refer to JEUS Server Guide. "2.2. Adding Servers" for more information about VM options.
-Djeus.servlet.jsp.modern=false
VM options can be replaced at the virtual host or web context level, and the settings in jeus-web-dd.xml are applied last. If the option is not set in jeus-web-dd.xml, the default configuration of the parent will be applied.
Using this option is only recommended when backward compatibility is required. For new application developments, it is recommended to use the current standards
Note
For information about other options, refer to JEUS Reference Book. "1.6. Web Engine Properties".