David Navas wrote:
> > 3) Custom tags. Tag.release() must be called in a finally block by a JSP 1.1
>compliant
> > implementation of a custom tag.
>
> Tag.release implies that the end tag surrounds the entire use of the resources
> that the Tag defines. I don't think that that is a reasonable assumption, and
> there's already a really good example why -- useBean.
Tag.release can only be responsible for deallocating resources only needed to process
the
tag/scope of the tag.
However, tags can allocate resources that extend beyond the scope of the tag using the
"id"
attribute, which puts
an object that the Tag created (say a bean which could have been alternatively loaded
by
useBean) into the pageContext hashtable. In this case, Tag.release does not
de-allocate this
bean, releasePageContext does.
> > Implicitly, the JSP engine will allocate resources in the pageContext. Although
>not
> > explictly demanded by the specs, it should be safe to assume that
>releasePageContext()
> > will be called in service's finally block for JSP 1.1 compliant implementations
>(refer
> > to page 112 and 139 of the JSP 1.1 specs).
>
> Err, the javadoc I read noted a releasePageContext() call in the JspFactory, not
> one on the JSPServlet. Did I miss this? releasePageContext() did seem a
> natural place to release transient, system resources, though not ideally named....
releasePageContext is a factory method, and indirectly gets called by the JSPServlet's
service method:
>From page 112 of the JSP 1.1 specs:
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
JSPFactory factory = JSPFactory.getDefaultFactory();
// Get the page context object for this page
PageContext pageContext = factory.getPageContext(this, request, response, null, //
e.g. no
errorPageURL,
false, // e.g. no session
JspWriter.DEFAULT_BUFFER,
true // autoflush=true
);
try {
// body of JSP here ...
} catch (Exception e) {
out.clear();
pageContext.handlePageException(e);
} finally {
out.close();
factory.releasePageContext(pageContext);
}
}
Now in the servlet generated by the JSP engine, the implementation should look
something like
this (page 77 of the specs):
final public void service(ServletRequest req, ServletResponse res)
throws ServletException, IOException {
// casting exceptions will be raised if an internal error.
HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) res;
_jspService(request, resonse); // therefore the factory method releasePageContext
will
always be called
}
> > No, it is the responsiblity of the tag author to free up resources before
><jsp:forward>
> > (ie: "a goto and never return") is called. <jsp:forward> means that the rest of
>the
> > page will never be called, including releasePageContext. Like in C, use goto's
>with
> > caution!
>
> Sure, I agree. The problem isn't with <jsp:forward>, which is an explicit goto.
> The problem is with arbitrary, 3rd-party tags which perform forwards. Possibly
> conditionally. Which makes resource deallocation somewhat non-trivial, yes?
There are worse things a 3rd-party tag can do, like use its reference to the
pageContext
object and null out all references in the page, request, session, and application
scopes...
Use 3rd party
tags with caution, as they can be maliciously designed to kill your web app. Besides,
it is
the responsibility
of the tag to clean up after itself (OO design principles), and not for parent tags to
clean
up after any
arbitrary children it may have (which is definitely non-trivial).
--
Michael Hu, Paradox Team, Corel Corporation
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
