Drew Cox wrote:

> [snip]
> It's strange, but with a single controlling servlet, an issue arises whether
> to store shared resources in the ServletContext (application scope) or as
> members of the servlet itself.  I have been using the ServletContext for all
> of this stuff, but the lack application lifecycle events in Servlet 2.2 API
> makes it a little hard to ensure it is all cleaned up properly with the
> application goes down.  As Slava mentioned, the controlling servlet could be
> unloaded/reloaded at any time, so the init & destory methods do not
> neccesarily correspond to the application starting and stopping.
>

Originally, I tended to store shared stuff as instance variables in my controller
servlet.  However, the thing that switched my thinking was starting to use JSP for
the presentation logic -- it is incredibly easy for a JSP page to reference a
servlet context attribute, and incredibly difficult (if not impossible) for a JSP
page to gain a reference to a servlet instance so that it can call the servlet's
methods.  Hence, I put pretty much everything in servlet context attributes now.

(This is also the reason that my action classes are servlet-specific, rather than
being general purpose as Slava suggests.  In most cases, the final processing
inside my action class perform() method is to do a RequestDispatcher.forward()
call to the appropriate JSP page to display results, so it's going to be
servlet-API-dependent no matter what.  If I want to segregate business logic into
reusable chunks, I tend to use EJB session beans that are accessed from within my
web action classes.)

To deal with the lack of formal application lifecycle events, I currently run on
servlet containers that do not unload servlets except at container shutdown time.
This is definitely a kludge, but it works for my needs so far.

The lack of application startup/shutdown events in the servlet API is my single
highest priority change recommendation for the next round of spec development.
Fortunately, I'm in the "experts review" group for this spec, and I'm clearly not
the only one who thinks this is very important -- it's listed in the "Futures"
section of the 2.2 servlet spec.

>
> Thanks for giving me plenty to think about guys.
>
> Regards
>
> Drew Cox
>

Craig

===========================================================================
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

Reply via email to