Add jsp_precompile as a request parameter and send a request to the JSP file. This will make the jsp pre-compile. Why it is mentioned as pre compile instead of compilation is that, the request is not served. That is, the JSP will not be executed and the request will not be serviced. Just it will be compiled and the implementation class will be generated.
The jsp_precompile parameter may have no value, or may have values true or false. It should not have any other values like ?jsp_precompile=yes – this will result in HTTP error 500.
So the example for query strings to pre compile jsp files are
?jsp_precompile
?jsp_precompile=true
?jsp_precompile=false
?foobar=foobaz&jsp_precompile=true
?foobar=foobaz&jsp_precompile=false
How to do pre compile for a bunch of JSP files? for all JSPs in a folder or application?
There are no special features available for this in the JSP specification. But the application servers (JSP containers) provide methods to do this on their own way. At the end of this tutorial we will see how to pre compile JSP files for Apache Tomcat 6.
But if you want to pre compile in server independent manner you have to use jsp_precompile request parameter and no other option available. To do it for the whole application, you can custome write a servlet or jsp file which will raise a request for all the JSPs available with jsp_precompile added as parameter.
Following JSP will pre compile all JSPs available in a folder and its subfolder:
<%@ page import="javax.servlet.*,javax.servlet.http.*,javax.servlet.jsp.* "%> |
<%@ page import="java.util.Set,java.util.Iterator,java.io.IOException"%> |
private void preCompileJsp(PageContext pageContext, JspWriter out, |
HttpServletRequest request, HttpServletResponse response, String uripath) |
throws IOException, ServletException { |
// getting jsp files list for pre compilation |
Set jspFilesSet = pageContext.getServletContext().getResourcePaths(uripath); |
for (Iterator jspFilesSetItr = jspFilesSet.iterator(); jspFilesSetItr.hasNext();) { |
String uri = (String) jspFilesSetItr.next(); |
if (uri.endsWith(".jsp")) { |
RequestDispatcher rd = getServletContext().getRequestDispatcher(uri); |
if (rd == null) throw new Error(uri +" - not found"); |
rd.include(request, response); |
else if (uri.endsWith("/")) { |
preCompileJsp(pageContext, out, request, response, uri); |
<html><head><title>Pre Compile JSP Files</title></head> |
HttpServletRequest req = new HttpServletRequestWrapper(request) { |
public String getQueryString() { |
// setting the pre compile parameter |
preCompileJsp(pageContext, out, req, response, "/"); |
JSP files Pre Compile Completed. |
How to pre compile JSP from command line?
Yes you can compile JSP files from command line. There are no specific tool promoted or authored by JSP specification or SUN. The right choice is to depend on application server for which we are compiling application or JSP the JSP files. Logic is to fork the JSP compiler mostly JSPC from command prompt using a utility like ANT.
I will give an example for the popular Apache Tomcat using ANT tool to pre compile JSP files. Important step is to write the ANT build script which will take through the compilation process. Using this ant script, either you can pre compile JSP files from command prompt or you can integrate the step of pre compiling JSP files into the build process which creates the distributable (WAR) file of your application.
Apache Tomcat 6.0 uses Eclipse JDT Java compiler to perform JSP java source code compilation.
<project name="Webapp Precompilation" default="all" basedir="."> |
<import file="${tomcat.home}/bin/catalina-tasks.xml"/> |
webXmlFragment="${webapp.path}/WEB-INF/generated_web.xml" |
outputDir="${webapp.path}/WEB-INF/src" /> |
<mkdir dir="${webapp.path}/WEB-INF/classes"/> |
<mkdir dir="${webapp.path}/WEB-INF/lib"/> |
<javac destdir="${webapp.path}/WEB-INF/classes" |
debug="on" failonerror="false" |
srcdir="${webapp.path}/WEB-INF/src" |
<pathelement location="${webapp.path}/WEB-INF/classes"/> |
<fileset dir="${webapp.path}/WEB-INF/lib"> |
<pathelement location="${tomcat.home}/lib"/> |
<fileset dir="${tomcat.home}/common/lib"> |
<fileset dir="${tomcat.home}/bin"> |
<exclude name="tags/**" /> |
<target name="all" depends="jspc,compile"> |
<fileset dir="${webapp.path}/WEB-INF/src"/> |
<fileset dir="${webapp.path}/WEB-INF/classes/org/apache/jsp"/> |
Use the above ant script and execute the following command to pre compile JSP files from command prompt:
$ANT_HOME/bin/ant -Dtomcat.home=<$TOMCAT_HOME> -Dwebapp.path=<$WEBAPP_PATH>
The benefits of pre-compiling a JSP page:
It removes the start-up lag that occurs when a container must translate a JSP page upon receipt of the first request.
Since the Java compiler is not needed, there will be a reduction of the footprint needed to run a JSP container.
In include directives, tag library references, and translation-time actions used in custom actions, compilation of a JSP page provides resolution of relative URL specifications.
The availability of a JSP object for use from a particular place of the application is defined as the scope of that JSP object. Every object created in a JSP page will have a scope. Object scope in JSP is segregated into four parts and they are page, request, session and application.
- page
‘page’ scope means, the JSP object can be accessed only from within the same page where it was created. The default scope for JSP objects created using <jsp:useBean> tag is page. JSP implicit objects out, exception, response, pageContext, config and page have ‘page’ scope.
- request
A JSP object created using the ‘request’ scope can be accessed from any pages that serves that request. More than one page can serve a single request. The JSP object will be bound to the request object. Implicit object request has the ‘request’ scope.
- session
‘session’ scope means, the JSP object is accessible from pages that belong to the same session from where it was created. The JSP object that is created using the session scope is bound to the session object. Implicit object session has the ‘session’ scope.
- application
A JSP object created using the ‘application’ scope can be accessed from any pages across the application. The JSP object is bound to the application object. Implicit object application has the ‘application’ scope.
Difference between forward and sendRedirect
forward
Control can be forward to resources available within the server from where the call is made. This transfer of control is done by the container internally and browser / client is not involved. This is the major difference between forward and sendRedirect. When the forward is done, the original request and response objects are transfered along with additional parameters if needed.
redirect
Control can be redirect to resources to different servers or domains. This transfer of control task is delegated to the browser by the container. That is, the redirect sends a header back to the browser / client. This header contains the resource url to be redirected by the browser. Then the browser initiates a new request to the given url. Since it is a new request, the old request and response object is lost.
For example, sendRedirect can transfer control from http://javapapers.com to http://anydomain.com but forward cannot do this.
‘session’ is not lost in both forward and redirect.
To feel the difference between forward and sendRedirect visually see the address bar of your browser,
in forward, you will not see the forwarded address (since the browser is not involved)
in redirect, you can see the redirected address.
When can we use forward and when can we use sendRedirect?
Technical scenario: redirect should be used
- If you need to transfer control to different domain
- To achieve separation of task.
For example, database update and data display can be separated by redirect. Do the PaymentProcess and then redirect to displayPaymentInfo. If the client refreshes the browser only the displayPaymentInfo will be done again and PyamenProcess will not be repeated. But if you use forward in this scenario, both PaymentProcess and displayPaymentInfo will be re-executed sequentially, which may result in incosistent data.
For other than the above two scenarios, forward is efficient to use since it is faster than sendRedirect.
Example for forward and sendRedirect based on real world
Consider the real world scenario, the milk man comes and asks for monthly payment to you in your house. Here house is the container and you are a resource existing in the container. Milk man is the client or browser.
He asks for the monthly payment to you, this is the request made by the browser to resource A. If you go inside your house and ask your mother (another resource B inside the same container) for the cash and come back and deliver to milkman this is called forward.
If you ask the milkman to speak himself to your mother inside your house or you ask the milkman to speak to your father who is in his office (different domain) then this is called redirect.
There is only one type of JSP comment available by JSP specification.
JSP Comment Syntax:
<%-- comment --%>
This JSP comment tag tells the JSP container to ignore the comment part from compilation. That is, the commented part of source code is not considered for the content parsed for ‘response’.
Example:
<%-- This JSP comment part will not be included in the response object --%>
Is this a JSP Comment?
<!-- comment --> is not a JSP comment. This is HTML comment. The JSP container treats this HTML comment tag as equal as any other HTML tags. When view source is done, the content given between this tag is visible. This is not anyway related to the JSP container, it is the expected behaviour of this HTML tag.
Example
<!-- This HTML comment part is included in the response object and can be seen in view source -->
// or
/* comment */ used inside the
<% %> scriplet tag is also not a JSP comment. This is just a java comment and JSP container doesn’t reserve any special treatment for this comments usage.
Therefore, there is nothing called as hidden comment or output comment in JSP by specification.
JSP Implicit objects are created by the web container. These implicit objects are Java objects that implement interfaces in the Servlet and JSP API. Scripting elements in a JSP page can make use of these JSP implicit objects. There are nine (9) JSP implicit objects available.
JSP Implicit Objects are as follows:
-
request implicit object
The JSP implicit request object is an instance of a java class that implements the javax.servlet.http.HttpServletRequest interface. It represents the request made by the client. The request implicit object is generally used to get request parameters, request attributes, header information and query string values.
-
response implicit object
The JSP implicit response object is an instance of a java class that implements the javax.servlet.http.HttpServletResponse interface. It represents the response to be given to the client. The response implicit object is generally used to set the response content type, add cookie and redirect the response.
-
out implicit object
The JSP implicit out object is an instance of the javax.servlet.jsp.JspWriter class. It represents the output content to be sent to the client. The out implicit object is used to write the output content.
-
session implicit object
The JSP implicit session object is an instance of a java class that implements the javax.servlet.http.HttpSession interface. It represents a client specific conversation. The session implicit object is used to store session state for a single user.
-
application implicit object
The JSP implicit application object is an instance of a java class that implements the javax.servlet.ServletContext interface. It gives facility for a JSP page to obtain and set information about the web application in which it is running.
-
exception implicit object
The JSP implicit exception object is an instance of the java.lang.Throwable class. It is available in JSP error pages only. It represents the occured exception that caused the control to pass to the JSP error page.
-
config implicit object
The JSP implicit config object is an instance of the java class that implements javax.servlet.ServletConfig interface. It gives facility for a JSP page to obtain the initialization parameters available.
-
page implicit object
The JSP implicit page object is an instance of the java.lang.Object class. It represents the current JSP page. That is, it serves as a reference to the java servlet object that implements the JSP page on which it is accessed. It is not advisable to use this page implict object often as it consumes large memory.
-
pageContext implicit object
The JSP implicit pageContext object is an instance of the javax.servlet.jsp.PageContext abstract class. It provides useful context information. That is it provides methods to get and set attributes in different scopes and for transfering requests to other resources. Also it contains the reference to to implicit objects.
Difference between JSP include directive and JSP include action
- <%@ include file=”filename” %> is the JSP include directive.
At JSP page translation time, the content of the file given in the include directive is ‘pasted’ as it is, in the place where the JSP include directive is used. Then the source JSP page is converted into a java servlet class. The included file can be a static resource or a JSP page. Generally JSP include directive is used to include header banners and footers. The JSP compilation procedure is that, the source JSP page gets compiled only if that page has changed. If there is a change in the included JSP file, the source JSP file will not be compiled and therefore the modification will not get reflected in the output.
- <jsp:include page=”relativeURL” /> is the JSP include action element.
The jsp:include action element is like a function call. At runtime, the included file will be ‘executed’ and the result content will be included with the soure JSP page. When the included JSP page is called, both the request and response objects are passed as parameters. If there is a need to pass additional parameters, then jsp:param element can be used. If the resource is static, its content is inserted into the calling JSP file, since there is no processing needed.
Difference between _jspService() and other life cycle methods.
The contents what we write in the JSP will go into _jspService() because we are implicitly implementing it. If we again try to override it explicitly, JSP compliler will giver error as ‘the method is already implemented and cannot override’. But in the case of other two methods we are not implementing it in the JSP. Therefore the JSP compiler will allow to override jspInit() and jspDestroy().
To show this difference _jspService() method is prefixed with ‘_’ by the JSP container and the other two methods jspInit() and jspDestroy() has no special prefixes.
JSP Life Cycle – explain.
1. JSP Page Translation:
A java servlet file is generated from the JSP source file. This is the first step in its tedious multiple phase life cycle. In the translation phase, the container validates the syntactic correctness of the JSP pages and tag files. The container interprets the standard directives and actions, and the custom actions referencing tag libraries used in the page.
2. JSP Page Compilation:
The generated java servlet file is compiled into a java servlet class.
Note: The translation of a JSP source page into its implementation class can happen at any time between initial deployment of the JSP page into the JSP container and the receipt and processing of a client request for the target JSP page.
3. Class Loading:
The java servlet class that was compiled from the JSP source is loaded into the container.
4. Execution phase:
In the execution phase the container manages one or more instances of this class in response to requests and other events.
The interface JspPage contains jspInit() and jspDestroy(). The JSP specification has provided a special interface HttpJspPage for JSP pages serving HTTP requests and this interface contains _jspService().
5. Initialization:
jspInit() method is called immediately after the instance was created. It is called only once during JSP life cycle.
6. _jspService() execution:
This method is called for every request of this JSP during its life cycle. This is where it serves the purpose of creation. Oops! it has to pass through all the above steps to reach this phase. It passes the request and the response objects. _jspService() cannot be overridden.
7. jspDestroy() execution:
This method is called when this JSP is destroyed. With this call the servlet serves its purpose and submits itself to heaven (garbage collection). This is the end of jsp life cycle.
jspInit(), _jspService() and jspDestroy() are called the life cycle methods of the JSP.
0 comments:
Post a Comment