In a 2.1-compliant servlet engine that supports preloading a servlet at startup
time, this is how I deal with the design issue you raise:
* Define a startup servlet that acquires all the needed
resources for my application in its init() method.
This servlet does not need a service/doGet/doPost
method, because it should never be invoked by a user.
* As the resources get acquired, store them in the
servlet context with:
getServletContext().setAttribute("resourceKey", resourceObject);
In your case, you would probably acquire your
"creator" objects through JNDI, or however you
do it in standalone applications. You can pass
initialization parameters to the startup servlet
to avoid hard coding names and paths, if you like.
* Configure my servlet engine to preload the startup
servlet when the server starts up.
* Once the server is running, and the startup servlet
has completed, the resources you acquired are available
in the servlet context to all servlets in your app:
Object resource =
getServletContext().getAttribute("resourceKey");
(Obviously, you would use the appropriate class name
and a cast for whatever object type your resource
really is).
* If your app is using JSP pages, these resources are
also visible to them, as beans with application scope.
* As an extra bonus feature, when the servlet engine is
shut down, it will call the destroy() method of your
startup servlet, which you can use to gracefully clean
up the resources that were acquired at init() time.
As long as the servlet engine does not decide to destroy your startup servlet
for some other reason (no guarantees on this in the spec), it makes a pretty
good "poor man's application server" platform.
Craig McClanahan
Chris Gow wrote:
> Hi:
>
> I was wondering how other developers got around the problem I am now facing.
> I am about to start working on a project that is going to use Servlets
> extensively, but I am running into a problem in determining the best
> approach to take to allow the Servlets communicate with non-servlet based
> classes (business classes).
>
> For example, a Database Connection pool. Most discussions about this topic
> involve using a Singleton pattern and just getting a connection from the
> pool when one is necessary. Thats nice and all and is in fact the approach
> I have taken in all the Servlets that I have developed up to this point.
> But what if you have 5, 10 or more Servlets that need to use the the same
> Connection Pool? Which one is responsible for initializing the pool? All
> of them? If that is the case, that might cause problems when maintaining the
> system (one class sets the wrong parameter).
>
> My situation is similar to that, except the Objects that my Servlets will
> communicate with are business objects like CustomerCreator, InvoiceCreator,
> ShipmentCreator, etc...In application development, since I am in control of
> what gets started when and setting up the communication links between
> Objects and classes, I have never had problems. But with Servlets, I can't
> think of a similar approach other than the Singleton design pattern.
>
> I was just wondering how developers who have developed larger servlet based
> applications got their Servlets and their Business Objects to talk to each
> other....
>
> Thank you in advance,
>
> Chris Gow
> [EMAIL PROTECTED]
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
