tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Guillemot" <>
Subject Re: Rooting request to one or an other webapp
Date Thu, 31 Jul 2003 08:56:34 GMT
Hi Yoav,

thanks for the info. Could you give me a link or the keywords permitting to
find the previous discussions you mentioned on this subject? I've search for
that but I didn't found anything. I guess that I've looked for the bad


----- Original Message -----
From: "Shapira, Yoav" <>
Newsgroups: gmane.comp.jakarta.tomcat.user
Sent: Wednesday, July 30, 2003 3:17 PM
Subject: RE: Rooting request to one or an other webapp


>does someone know a way to catch a request and to forward it to one or
>other webapp according to some runtime settings?
>The idea is to be able at runtime to smoothly add a webapp, set it as
>default, and to remove the one that was the default when it has no
>session anymore.

Something similar to this has been requested and discussed several times
(it's generally a bad idea), so you can search this list's archives for
more information.

Broadly speaking:

- Let's call webapp1 the one to be removed
- Let's call webapp2 the one to be added

You would need:
- A session listener in webapp1 maintaining a session count, and having
a public static int getSessionCount() method.
- A filter in webapp1 mapped to /* which consults the session count each
time and if 0 (or whatever other runtime setting you choose, e.g. a
context param), forwards requests to webapp2
- Maybe an admin JSP (or some other means) in webapp1 to set the runtime
settings for the filter
- Once you see the above happening, you can remove webapp1 via the
manager webapp

Of course, there are caveats:

- Initially the session count for webapp1 will be zero, so the filter
will forward, unless you also have a runtime setting for the filter that
says "don't forward"
- If you want to remove webapp1 programatically, you will need some
classes to be in the common/lib repository, not web-inf/lib, as these
classes will need to access tomcat internals (making them non-portable).

Yoav Shapira

This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message