Hi Drew,
I'm also benefiting from this discussion. Even though I already
implemented my own solution, which looks suspiciously like everybody's
;), it's good to hear other people's opinions to see why they chose
other options. So I'll add my 2c:
Well, I'm using the servlet context approach and I'm passing it directly
to the WebAction so its perform method has a signature that looks like:
/**
abstract protected OperationResult
_performOperation(ServletContext theContext, ServletRequest theRequest)
throws Operation Exception
**/
I don't pass the response because I don't want the subclasses to deal
themselves with it. The abstract class itself does this work and I don't
want the action's developers to play with the response unless they need
to. In case they need to play with it directly, I have another subclass
of operation that allows them to. And I return as a result an object of
a specific class, instead of void, because it is sometimes useful to
know whether the action performed correctly or not wihout requiring an
exception to be thrown, oh! and because I let the operation store there
the objects that he wants to be set as attributes in the response.
Regarding your open issues... for security I use a class, Sentinel,
which checks the security for every action invocation that requires it
(security is not mandatory ). I wanted to control the timing out of
users' sessions, their log out... so this class handles a reduced cache
of active connections... And I allow users, roles, permissions to be
defined through interfaces so I can get them from XML, a DB, RMI... so
this class also handles this. I've found it very useful and interesting
because now I can use this class for every application, but it has also
been the hardest part to develop/debug as I wanted it to answer
something more than access denied; Our library answers "user doesn't
exist, wrong password, session timeout..." but I think it's worthy
because users get a more meaninnful response.
Regarding application lifecycle, as the issue is still open in the
Servlet API I developed my own scheme. I have my WebActions defined as
part of "Applications", and each Application has its own state and its
own ApplicationLifeCycleHandler. The controller servlet is in charge of
calling the appropriate methods of the handler at the appropriate times.
So I initialize the shared resources inside the
Application.onStart(ServletContext theContext) method, and I clean them
up inside the Application.onStop(ServletContext theContext). Then you
just have to make sure that the controller servlet calls this methods in
its init and destroy methods. If your controller servlet is
loaded/unloaded repeteadly you'll get into performance problems but you
should be able to configure your servlet engine for this not to
happen(or follow Craig's approach).
I hope this helps, good luck with it.
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
Drew Cox wrote:
>
> Thanks to Craig and Slava for your well thought out and explained opinions.
> This stuff is gold, I hope others are benefitting as much as I am. Some of
> your sample code looks so much like what we have written it's freaky, except
> that it shouldn't be, because the design I am using is completely based on
> what I have learned participating in this list.
>
> For a little restrospective clarification, Slava was correct when he
> suspected I was passing an identical list of additional parameters to the
> web action perform( ) methods for the application services (reflected in the
> perform( ) method signature in thw WebAction interface they implement).
> Also that that the proposed Hashtable of services would be cached at the
> application scope, not rebuilt for each call.
>
> I actually delegate the building of the web action hash table and req
> dispatching to a separate WebActionManager class, which as with Craig's
> design, keeps the controlling servlet quite small. The WebActionManager
> would also appear to be a good place to invoke any security functionality,
> eg. is the current user allowed to access this action. I am yet to finalise
> this part of the system, so another design review is probably pending...
>
> 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.
>
> Thanks for giving me plenty to think about guys.
>
> Regards
>
> Drew Cox
>
*** Cut for brevity's sake
===========================================================================
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
