Kris Schneider

Bear Bibeault wrote:You'll either need to chain them on the client...

Never used these, but you get the idea...

http://code.google.com/p/jquery-ajaxq/
http://www.protofunc.com/scripts/jquery/ajaxManager/
http://plugins.jquery.com/project/ajaxqueue

There can be some fairly significant differences, like allowed servlet instance pooling, but SingleThreadModel was deprecated in Servlet 2.4...

http://tuckey.org/urlrewrite/

Tomcat contains something like the following in conf/web.xml (inherited by all apps):

<servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <init-param> <param-name>listings</param-name> <param-value>false</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

Which basically means that there's always a servlet operating on any request to an app...regardless of what kind of resource it might be classified as...

Parthiban Mahiby wrote:So please clarify me.

There are a few things you really should change, like not really sending a response from the servlet, but add a little more detail to your logging first:

public class MyServletRequestListener implements ServletRequestListener { public void requestInitialized(ServletRequestEvent sre) { System.out.println("Request Initialized: " + ((HttpServletRequest)sre.getServletRequest()).getRequestURI()); } public void requestDestroyed(ServletRequestEvent sre) { System.out.println("Request Destroyed: " + ((HttpServletRequest)sre.getServletRequest()).getRequestURI()); } }

Amol Nayak wrote:Are you saying there are explicit mappings to static resources like *.jpg, *.bmp , *.html etc to some servlets and filters? Well that is unlikely, even if you do, the request will be intercepted by the Servlet/Filter and the requested resource will be served to you only if the Servlet/Filter has the logic to do so.

I guess my point is that trying to use the concept of "static resources" to understand why a request listener is getting created isn't helpful. The API docs define exactly the conditions under which it happens.

Amol Nayak wrote:Having a look at the web.xml can give us some clues.

Sure, in addition to finding out what the actual request for the "static page" looks like (path, params, etc.).

Amol Nayak wrote:The object will be created only if the reqest if for a Dynamic resource (JSP or servlet) and not for any static resource on the Server.

Maybe. The API docs are a bit more specific:

A ServletRequestListener can be implemented by the developer interested in being notified of requests coming in and out of scope in a web component. A request is defined as coming into scope when it is about to enter the first servlet or filter in each web application, as going out of scope when it exits the last servlet or the first filter in the chain.

So, depending on how you define "static resource", having filters or servlets operate on the request will cause a request listener to be created...

Jianping Wang wrote:Forget to mention: I use Tomcat 6.0.20

One thing you should definitely try is upgrading to 6.0.26. There has been a fair amount of recent work targeted at memory leaks...

Rajeev roushan sharma wrote:

David Newton wrote:There's a "work" directory that contains each app's intermediate files.

Thanks :) I did not get any intermediate file under work folder. Is there any way to configure where to put compiled JSP's intermediate java and class file ?

http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html#Configuration

Make sure keepgenerated has not been set to false.

Try playing with scratchdir to use a different directory.

William Brogden wrote:You should NEVER NEVER try to keep a copy of a session reference longer than a single request/response cycle.

+1
Nor should you use that reference outside of the request-handling thread...

It might also help to look at the actual schema for web.xml to see how the filter-mapping element is defined: http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd

I've attached an image produced by JDeveloper to help visualize the structure...

The error in the original post is usually caused by a scriptlet expression that does not appear by itself as an attribute value. For example, this should work fine:

<% String pg = request.getParameter("page"); %> <jsp:include page="<%= pg %>"/>

But this will cause the error:

<% String pg = request.getParameter("page"); %> <jsp:include page="<%= pg %> "/>

By the way, don't use page for the scripting variable name, it's already defined as an implicit object...

Garrett Smith wrote:Google search results yeilded this thread, a PDF from oracle that crashed Firefox, and a links on jcp.org that resulted in no server response.
...
Where can I get the official specification?

There were definitely some problems with jcp.org, but they seem to have been resolved:

JSP 2.0: http://jcp.org/aboutJava/communityprocess/final/jsr152/

Garrett Smith wrote:Brain dead, recursive definition.
http://www.oracle.com/technology/sample_code/tutorials/jsp20/simpleel.html

" The empty operator is a prefix operation that can be used to determine if a value is null or empty."

Doesn't say whether or no "" is empty, does it?

For better or worse, that's actually a quote from the JSP 2.0 Spec. (section JSP.2.3.7). However, the spec. also provides some detail to give the definition of "empty" some context:

To evaluate empty A
• If A is null, return true,
• Otherwise, if A is the empty string, then return true.
• Otherwise, if A is an empty array, then return true.
• Otherwise, if A is an empty Map, return true,
• Otherwise, if A is an empty Collection, return true,
• Otherwise return false.

Even with the additional detail, it's still fair to take issue with the "recursive" use of "empty" instead of something like:

To evaluate empty A
• If A is null, return true,
• Otherwise, if A is a String, then return A.length() == 0.
• Otherwise, if A is an array, then return A.length == 0.
• Otherwise, if A is a Map, return A.isEmpty(),
• Otherwise, if A is a Collection, return A.isEmpty(),
• Otherwise return false.

It looks like the flushing of some of the original JSP's content to the output stream is causing the error page mechanism to fail. Which makes some sense, since the response has already been committed before the exception is thrown. In the long-run, you may want to move that processing into a filter or servlet, but here's something you might try for now - make sure you specify a large enough buffer so that partial contents don't get flushed:

<%@ page buffer="100kb" %> <%-- default is "not less than 8kb" --%>

...or just try removing buffer="none" if you have it set...