See embedded comments:
"Hines, Bill" wrote:
>
> Craig,
>
> I understand. One thing, however - I still was going to have the main
> "controller" servlet that was going to do the routine things - check for
> login, check for session, etc. Then *that* controller servlet was going to
> instantiate the Action servlet and call its doGet(). But as you say, that
> would be overkill since the Action servlet would carry a lot of unnecessary
> baggage.
>
>
I was thinking of the amount of baggage that the JVM has to create and
then garbage collect. And thinking of servlet lifetimes etc.
Not sure what you guys think of the following points but:
1. for _really_ high volume actions, if the action is totally thread
safe, then you only need to instantiate one object - just ensure the
doIt (or whatever it's called) is safe. (and I'm sure we're all doing
that anyway).
2. It would be possible to define an action with a "fuller" lifecycle if
need be. For example define an Action interface that also has
init(ServletContext c) and destroy() methods on it - but I suppose then
you might as well right a servlet instead.
I can see that doing Model 2 implementations and a framework it is
really quite easy to get carried away. Without thought you could end up
re-implementing features provided by your servlet engine/ JSP engine.
Still, defining a full lifecycle interface for an action would give you
the choice of putting all your controller code in the same point (either
easy to remember where it is, or a bottleneck - you choose ;). It also
makes you independent of the servlet engine for configuration and other
issues. That could be an advantage if you need different ways of dealing
with failover, or configuration, or restarting parts of a server without
having to restart the lot.
Examples:
- on a heavily used live site, use a "management" interface into your
dispatcher to prompt it to reload and recheck its configuration -
allowing you to add/change action mappings at runtime without bringing
down the server.
(although I guess this may not be an issue if you can shut down and
restart using load balanced servers to maintain service).
I suppose the problem is that you may end up duplicating functionality
available from the servlet engine itself, or writing code that should
really be part of the next release of the engine (e.g. for Tomcat).
Comments?
Anyone actually found a need to do this?
--
Jari Worsley
Senior Programmer
Hyperlink plc
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
