JavaSercer Pages You can solve this problem by

JavaSercer Pages You can solve this problem by using a bean with a regular method that takes the URI as an argument, instead of setting the URI with one setter method and incrementing the corresponding counter value with another method that depends on the URI value set by the first. This way, the method gets all the information it needs in one shot, and there’s no risk of interference by other threads. 8.2.2 URL Rewriting As I mentioned earlier, the session ID needed to keep track of requests within the same session can be transferred between the server and the browser in a number of different ways. One way is to encode it in the URLs created by the JSP pages, called URL rewriting . This approach works even if the browser doesn’t support cookies (perhaps because the user has disabled them). A URL with a session ID looks like this: counter3.jsp;jsessionid=be8d691ddb4128be093fdbde4d5be54e00 When the user clicks on a link with an encoded URL, the server extracts the session ID from the request URI and associates the request with the correct session. The JSP page can then access the session data in the same fashion as when cookies are used to keep track of the session ID, so you don’t have to worry about how it’s handled. What you do need to do, however, is to call a method that lets the JSP container encode the URL when needed. To see how it’s done, let’s create two pages that reference each other using a regular HTML link. A CounterBean in the session scope is used to increment a counter for each page. Example 8.5 shows one of the pages. The other page is identical, except for the title and the link at the bottom. Example 8.5. Page with an Encoded Reference to Another Page (counter2.jsp) <%@ page language="java" contentType="text/html" %> <% String uri = request.getRequestURI( ); %>

Counter page 1

This page has been visited <%= sessionCounter.getNextValue(uri) %> times by the current user in the current session.

Click here to get to “> Counter page 2. The only differences compared to Example 8.4 are that only the session counter is used, and the link to the other page has been added. The element’s href attribute value is converted using the encodeURL( ) method of the implicit JSP response object, described in Chapter 6. If a cookie is used to transfer the session ID between the browser and server, the encodeURL( ) method just returns the URL untouched. But if the browser doesn’t support cookies, or cookie support is disabled, this method returns the URL with the session ID encoded as a part of the URL, as shown earlier. If you want to provide session tracking for browsers that don’t support cookies, you must use the encodeURL( ) method to rewrite all URL references in your application: in tags,

tags, and tags. This means all pages in your application (or at least all pages with references to other pages) must be JSP pages, so that all references can be dynamically encoded. If you miss one single URL, the server will lose track of the session. I recommend that you take the time to add encodeURL( ) calls for all references up front, even if you know that all your current users have browsers that support cookies. One day you may want to extend the user base and lose control over the browsers they use. It’s also common that users disable cookies in fear of Big Brother watching. Yet another reason to prepare for URL rewriting from the beginning is to support new types of clients that are becoming more and more common, such as PDAs and cell phones. Cookie support in these small devices is not a given. page 97

Hint: If you are looking for very good and affordable webspace to host and run your java hosting application check Sandzak.com java web hosting provider


Comments are closed.