In the web.xml file (and in Java programming in general), always use "/" as the path seperator. Do not use the MS-DOS/Windows "\" path seperator.

A ServletContext provides a view of the application that the Servlet, Filter, or JSP is running in. The ServletContext models the Web Application. A ServletContext is an object that is common to all Servlets in an application.

A ServletContext is represented by a object.

Every time a user follows a URL that points to a Servlet or JSP within the Web Application, Resin creates a Request object to represent the current request. Resin also creates a Response object which the developer can use to set certain things that apply to the response to the users browser.

A request is represented by a object. A response is represented by a object.

A Session is established for each user of the web application. The first time a user accesses anything within the web application, Resin recognizes this unknown user and creates a new Session to represent them. This Session object will remain the same for that user for the duration of their use of the web application.

A session is represented by a object.

The Session is created the first time a user access a component in the web application that requests the session. Resin sees the incoming request from a user and checks to see if it has a Session for that user. If it does not, it creates one. This session object will remain the same for that user.

The end of the session object is a bit complicated. Since Resin cannot tell the difference between when the user has stopped using the application and when the user is just taking a long time to do something, Resin must guess. Resin uses a time-out value to determine when it should assume that the user has gone away, it defaults to 30 minutes. What this means is that if a user has not accessed any resource in the Web application for 30 minutes the Resin will destroy the session object for that user.

A developer can also explicitly destroy the Session object, and that is discussed later.

The Servlet implementation class usually obtains the ServletContext in the init() method. The request and response object are passed in the doXXXX() method. The request object is used to obtain the Session.

When translation of a JSP to a Servlet occurs, there are some variables that are automatically defined. These variables can be used within any Java code that is inserted in the page.

The following methods are available for the application, session, and request objects.

Probably the most important and most frequent usage of the response object is to rewrite the URL. Recall from earlier that in order to maintain the identity of a Session with the user Resin may have to add a special parameter to every URL. The developer must co-operate with this, using the response.encodeURL method.

Because of this, it is a good idea to form a String for every URL you will use in a page and store it in a variable:

This has the added benefit of placing all of your URL's in one place, allowing you to change them more easily.

Sometimes it is desirable to send a redirect to the client. This is a response to the client that tells it to go to some other URL. This is often used by developers so that the URL in the browser makes sense to the user. It is however, a slow procedure because it requires a response to go all the way back to the browser, and then the browser will make a new request.

The redirect is accomplished by using the response.sendRedirect() method. Again, the URL must be encoded, and a special kind of encoding is needed for a redirect:

As mentioned eariler, the <%@ page contentType="..." %> directive can be used to tell the browser the type of content that it is getting.

The page directive method does not allow you to do this dynamically. You can instead use: response.setContentType("...") to set the content type.

Often it is necessary to inform the browser that a page should not be cached - the browser should ask for a new copy of the page every time. The best way to do this is by setting appropriate HTTP headers in the response to the browser.

Unfortunately, all the browsers work differently. The following seems to be a consensus on the headers to set:

A little known fact is that it is necessary to inform the browser with certain pages that they are private pages, meaning they should never be seen by anyone except the current user.

This applies to any pages that the user has needed a password to get to.

The main use of the request object is to get the values that a user has supplied in a form submit. For example, with this HTML on page a.jsp:

The value that was supplied in ``eggs'' can be retrieved with:

The session object will go away if the user is inactive for a certain time (usually 1/2 hour). You can also explicitly destroy the session, which you may want to do for example if the user chooses to logout.

This is accomplished with: session.invalidate();

It is possible to add a hook so that something can be done when Resin decides that a Session has expired, or the Session is explicitly destroyed.

To accomplish this, you write a class that implements the interface. Then you register this class with the session simply by putting it as one of the attributes. The Session will notify all of it's attributes that implement .

It is important to realize that the user can have multiple windows open that use the same session. If the user uses the "Open in new Window" functionality of a browser, they will have two windows open and the Web Application will see them both as belonging to the same session. This has some ramifications on how the Session can be used for shopping-cart like applications.

For example, let's assume that an application uses the Session attribute "cart" to store shopping cart information about different types of juice a user has chosen to purchase.

The user may start one juice buying transaction and get to the confirmation page, having 3 grape and 2 apple in their cart. Now, what happens if at this point they use another browser window to initiate another purchase? If the Web Application is using the Session to store shopping cart information then the second window may destroy the contents of the shopping cart, so that if the user finishes the first window they end up buying nothing!

A possible solution for this is to keep a version counter in your cart. Every time the cart is changed, the version counter is updated. Then, when your application shows the "confirm purchase" page (the next action will cause the purchase to occur), it sends the version counter to the "confirm purchase page". The "confirm purchase" page submits that version counter as a parameter. The application can check the submitted version counter, and the current version counter in the shopping cart - if they are different then the cart has been modified in some other way, and a message is returned that the purchase did not occur because the cart had been modified elsewhere.

Some errors may occur at JSP translation time. This could be, for example, from an error in the syntax of some Java code in your JSP. You will usually see this error in your browser the first time you try to access the page. Resin can also put the error in log files.

From the JSP specification:

Some errors may occur at the time a Servlet or other source file is being compiled by Resin. This could be, for example, from an error in the syntax of the Java code. You will usually see this error in your browser the first time you try to access the page. Resin might also put the error in log files.

Java handles runtime errors with exceptions. If an exception is not caught in your JSP or Servlet, Resin will use a special error page to send results back to the browser. Resin uses a default error page unless you explicitly provide an error page yourself.

From the JSP specification:

The simplest model is to use JSP as an add-on to existing web pages. At the top of each page is the Java code that is necessary for the display of the page, and at the bottom is the markup that is to be output, with appropriate insertion of any dynamically generated variables.

Note the seperation of the different logical parts. It is a very good idea to keep the presentation section as Java-less as possible. Setup all of the values in the logic part, and then use only simple <%= var %> and if statements in the presentation part.

This seems like a sensible approach. However, imagine that later it is decided that a different set of HTML is needed for the output if there is no news available. As well, support of WML output is required. Now we need to put the display code for 4 different types of output into one page. Maybe we need to go to different places as well, for example an administrator might get a different display page, or we need to check the users profile to see what is apporiate to display. This is too much complication to put all in one place.

This type of implementation, because of it's limitiations and it's inability to change without exponentially increasing the complexity, should be avoided.

To address some of the disadvantages of the Simple JSP method, it is possible to seperate the `logic' and the `presentation' into two different JSP files.

In this model, instead of a link pointing directly to the page that does the display, it points to a page that handles the incoming request. This 'logic' page contains the Java code that is responsible for preparing the values that will be used for displaying. It stores these prepared values as attributes of the request object, and then forwards to the appropriate display page. The display page then pulls the information it needs out of the request object and displays it.

Here we have introduced a new thing: pageContext.forward.

The pageContext.forward(String url) forwards the processing to a different JSP page. That is, it passes control over to another page. This page is then executed, inheriting the current request and response objects. It is important that this is the last thing that a JSP page does.

Even the seperation of all logic into a different JSP can get a bit muddled. You can seperate the `logic' into two types of logic, business logic and presentation logic.

Presentation logic is logic that is part of the presentation. Examples are form validation and formatting of numbers into strings.

Business logic is programming that involves your data. If you can separate something in your mind from the presentation, it doesn't depend on the presentation in any way, that's business logic. Examples are database lookups and shopping cart manipulation.

Your application will be cleaner and easier to manage if you put your business logic in Java classes (beans) which hide the complexities. You then use these classes in the logic.jsp.

The final approach discussed here is called the `Model 2' approach. This approach requires a level of sophistication that is usually not warranted unless you use a library that supports it, however it is the cleanest way to implement an application.

In this approach there is a special Servlet called a controller servlet. The controller maps an incoming request to a Java class that takes care of all of the 'business logic'. This Java class returns a result that indicates to the controller where it should go next. The controller then dispatches to the appropriate place.

The flow of a request moves through these `business logic' pieces, finally ending up at a `view'. The logic pieces are responsible for examing the submitted information (such as parameters from forms), managing logical flow, and preparing objects for the view. The objects for the view are stored as attributes of the request (or sometimes, the session).

The view is responsible for preparing a response for the user using the prepared objects now available as request or session objects. This is where JSP is often used, it works very well as the view component of a Model 2 architecture.

The developer tells the controller what the flow for each request is by specifying it an external (usually XML) file.

This approach is by far the cleanest approach to using Servlets and JSP. Most applications of any significant complexity use a Model 2 architecture.

A Principal is established in association with a Session. There is a one to one correspondence between the two. Usually the Principal is a user, a real live honest to goodness person sitting at a computer somewhere and accessing the Web Application.

The Application may require that the User go through a login process, a successful login will establish a Principal, which will have a certain set of Roles.

Roles are similar to groups in Unix security. As an example, you might have a "member" role for users who have a membership, and an "admin" role for administrators.

Principals can have more than one role -- a user might be both a "member" and an "admin".

Servlet 2.2 Specification states:

Basically what this means in real terms is that you can specify certain paths in web.xml that require certain roles. For example, you can say that to access any page in the "/accountsetup/" subdirectory, the user must have a role of "admin".

Servlet 2.2 Specification states:

Programmatic security lets you decide in some Java code what to do, based on the role that a user has. For example, you might make a certain button appear in the button bar only for an "admin" user.