> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of Craig R. McClanahan
> Sent: Sunday, January 16, 2000 11:09 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Providing application resources to action classes in
> single-servlet delegation model
>
....
>
>
> As you can see, I'm passing a reference to the calling servlet
> (passed as "this"),
> along with the specific request and response I am dealing with.
> (Alternatively, I
> suppose you could make the servlet a JavaBeans property of the
> action class, and
> have the controller servlet set it the first time that the action
> instance is
> loaded).
Firstly, I believe the alternative is dangerous - I don't believe the
Servlet API guarantees the longevity of individual servlet objects. Servlet
engines can kill off servlet objects and restart them as they see fit
(including during development). Please correct me if I'm wrong. This would
mean that the servlet reference that a WebAction was initialized with could
grow stale and revert to null, crashing the WebAction when it tries to
dereference it.
> Passing the servlet reference lets me access any resources that
> the underlying
> servlet can get.
...
> If the controller servlet itself had methods you wanted to treat as shared
> functionality for your action procedures, you could pass a
> reference to your
> servlet class instead of HttpServlet if you wanted. I've got a
> generic controller
> servlet that does all the common stuff (request parsing, loading
> and caching the
> action class instances, calling the correct one), which I can
> subclass to provide
> additional shared functionality that is unique to a particular
> web application.
>
Judgement call. The more stuff the controller does itself the more Godlike
it becomes. At some point it may makes sense to decompose it and its
functionality. Again, judgement call. :-)
> >
> > Currently I am just having the controlling servlet extract references to
> > these beans from the application scope and passing them as
> parameters to the
> > action class perform( ) method.
> >
>
> Doesn't that mean that the method signature for perform() changes for each
> action? That would seem to require changes to the controlling
> servlet as you add
> new actions that require different signatures. In my model, the
> call to perform()
> is the same for all actions.
>
I think Drew meant that each perform() method has the same signature, where
the parameter list includes all the various services.
...
> There is also a non-zero
> amount of work
> allocating a new Java object for the collection, and then filling
> it in -- and you
> are paying this cost on every single request.
>
I think Drew meant that there is but one services Hashtable which gets
initiated at some point in the beginning and gets passed around to every
invocation of perform(). Thus no additional per-request object creation.
> From a design viewpoint, there's an additional question. Let's
> say you've built a
> particular web action, and you want to enhance it. But now, it needs an
> additional resource out of the servlet context attributes that
> was not required
> before. Do you need to go back to your controller servlet and
> add an additional
> services object to the collection?
Unless you make up a mechanism to add services at runtime (either during
startup in a config file or dynamically somehow), I don't see how one gets
around the problem that: for every application-wide service that you add,
you need to change some core code somewhere (define "core code" as
non-WebAction). Either by adding a name/value pair to a Hashtable (either a
self-defined one or ServletContext's) or changing a factory method.
-s
Slava Kozlov
no, not the Red Wings' hockey player though we're the same age, same height,
same country of origin :-)
===========================================================================
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
