Servlets & JSP Series 7 - Being a JSP
?
- A JSP becomes a servlet: a sevlet that you do not create, the container looks at your JSP, translates it into Java source code, and compiles it into a full-fledged Java servlet class.
- The Container takes what you have written in your JSP, translates it into a servlet class source file, then compiles that into a Java servlet class, after that, it’s just servlets all the way down, and the servlet runs in exactly the same way it would if you had written and compiled the code yourself, in other words the Container loads the servlet class, instantiates and initializes it, makes a separate thread for each request, and calls the servlet’s service() method.
- We can put regular old Java code in a JSP using a scriplet-which just means Java code within a <% … %> tag. Directives come in three flavors: page; include; taglib.
- The Java code is between angle brackets with percent signs: <% and %>, but the directive adds an additional character to the start of the element-the @ sign; <% out.println %> equals <%= %>; three different JSP element types: Scriptlet <% %>; Directive <%@ %>; Expression <%= %>.
- The container takes everything you type between the <%= %> and puts it in as the argument to a statement that prints to the implicit response PrintWriter out, when the container sees this: <%= Counter.getCount() %> it turns it into this: out.print(Counter.getCount());. So Please NEVER end an expression with a semicolon.
- In an expression, if the method does not return anything, you will get an error, you cannot, MUST NOT use a method with a void return type as an expression, the Container is smart enough to figure out that there won’t be anything to print if the method has a void return type.
- The page directive is about giving the Container information it needs when translating your JSP into a servlet, the attributes we care about are import, session, content-Type, and isELIgnored.
- ALL scriptlet and expression code lands in a service method, that means variables declared in a scriptlet are always LOCAL variables.
- There is another JSP element called a declaration: <%! int count=0 %>; JSP declarations are for declaring members of the generated servlet class, that means both variables and methods, in orther words, anything between the <%! And %> tag is added to the class outside the service method, that means you can declare both static variables and methods. A JSP declaration is always defined inside the class but outside the service method.
- What the container does with your JSP: 1.Looks at the directives, for information it might need during translation; 2.Creates an HttpServlet subclass; 3.If there is a page directive with an import attribute, it writes the import statements at the top of the class file; 4.If there are declarations, it writes them into the class file, usually just below the class declaration and before the service method; 5.Builds the service method, the service method’s actual name is _jspServece(), it’s called by the servlet superclass’s overridden service() method, and receives the HttpServletRequest and HttpServletResponse, as part of building this method, the Container declares and initializes all the implicit objects; 6.Combines the plain old HTML, scriptlets, and expressions into the service method, formatting everything and writing it to the PrintWriter response output.
- The key methods of generated servlet from JSP: 1.jspInit()(this method is called from the init() method, we can override this method); 2.jspDestroy()(this method is called from the servlet’s destroy() method, we also can override this method);3. _jspService()(this method is call from the servlet’s service() method which means it runs in a separate thread for each request, we cannot override this method, we cannot do anything with this method ourselves, and it’s up to the Container vender to take our JSP code and fashion the? _jspService() method that uses it.
- You write the .jsp file, the Container writes the .java file for the servlet your JSP becomes.
- Lifecycle of a JSP: 1.You write a .jsp file, and deploys it as part of a web app, the Container “reads” the web.xml(DD) for this app, but does not do anything else with the .jsp file(until the first time it’s requested); 2.The client hits a link that asks for the .jsp, the Container tries to TRANSLATE the .jsp into .java source code for a servlet class; 3.The Container tries to COMPLE the servlet .java source into .class file; 4.The Container LOADS the newly-generated servlet class; 5.The Container instantiates the servlet and causes the servlet’s jspInit() method to run, the object is now a full-fledged servlet, ready to accept client requests; 6.The Container creates a new thread to handle this lient’s request, and the servlet’s _jspService() method runs, everything that happens after this is just plain old servlet request-handling, eventually the servlet sends a response back to the client.
- Translation and compilation happens only ONCE, when you deploy a web app with a JSP, the whole translation and compilation step happens only once in theJSP’s life, once it’s been translated and compiled, it’s just like any other servlet, and just like any other servlet, once that servlet has been loaded and initialized, the only thing that happens at request time is creation or allocation of a thread for the service method.
- We configure servlet init params for our JSP virtually the same way we configure them for a normal servlet, the only difference is that we have to add a <jsp-file> element within the <servlet> tag.
- We can use a PageContext reference to get attributes from any scope, including the page scope for attributes bound to the PageContext, the methods that work with other scopes take an int argument to indicate the scope, although the attribute access methods come from JspContext, we will find the constants for the scopes inside the PageContext class.
- Page directory contains 13 kinds of attributes: 1.import; 2.isThreadSafe; 3.contentType; 4.isELIgnored; 5.isErrorPage; 6.errorPage; 7.language; 8.extends; 9.session; 10.buffer; 11.autoFlush; 12.info; 13.pageEncoding.
- An EL expression always looks like this: ${something}, in other words, the expression is always enclosed in curly braces, and prefixed with a dollar ($) sign.
- It’s simple to make scriptlets invalid for a JSP to have scripting elements(scriptlets, Java expressions, or declarations) by putting a <scripting-invalid> tag in the DD: <scripting-web-app ...> ... <jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <scripting-invalid> true </scripting-invalid> </jsp-property-group> </jsp-config> ...</web-app>
- If you want EL-looking things in your JSP to be ignored, you have to say so explicitly, either through a page directive or a DD element (two methods): Putting <el-ignored> in the DD-<web-app ...> ... <jsp-confi g> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <el-ignored> true </el-ignored> </jsp-property-group> </jsp-confi g> ... </web-app>; OR Using the isELIgnored page directive attribute-<%@ page isELIgnored=”true” %>.
- The page directive takes priority over the DD setting, if there is a conflict between the <el-ignored> setting in the DD and the isELIgnored page directive attribute, the directive always wins, that lets you specify the default behavior in the DD, but override if for a specific page using a page directive.
- The page directive defines page-specific properties such as character encoding; The taglib directive defines tag libraries available to the JSP; The include directive defines text and code that gets added into the current page at translation time.
- JSP implicit objects contains: application, out, request, response, session.
?