RE: Rooting request to one or an other webapp

2003-07-31 Thread Shapira, Yoav

Howdy,
Look at the "Switching between releases during runtime" thread, and I
actually think Mr. Fiala ended up posting his complete solution on his
web page.

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Marc Guillemot [mailto:[EMAIL PROTECTED]
>Sent: Thursday, July 31, 2003 4:57 AM
>To: Tomcat Users List
>Subject: Re: Rooting request to one or an other webapp
>
>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
>terms.
>
>Marc.
>
>- Original Message -
>From: "Shapira, Yoav" <[EMAIL PROTECTED]>
>Newsgroups: gmane.comp.jakarta.tomcat.user
>Sent: Wednesday, July 30, 2003 3:17 PM
>Subject: RE: Rooting request to one or an other webapp
>
>
>
>Howdy,
>
>>does someone know a way to catch a request and to forward it to one or
>an
>>other webapp according to some runtime settings?
>>
>>The idea is to be able at runtime to smoothly add a webapp, set it as
>the
>>default, and to remove the one that was the default when it has no
>active
>>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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Rooting request to one or an other webapp

2003-07-31 Thread Marc Guillemot
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
terms.

Marc.

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



Howdy,

>does someone know a way to catch a request and to forward it to one or
an
>other webapp according to some runtime settings?
>
>The idea is to be able at runtime to smoothly add a webapp, set it as
the
>default, and to remove the one that was the default when it has no
active
>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Rooting request to one or an other webapp

2003-07-30 Thread Shapira, Yoav

Howdy,

>does someone know a way to catch a request and to forward it to one or
an
>other webapp according to some runtime settings?
>
>The idea is to be able at runtime to smoothly add a webapp, set it as
the
>default, and to remove the one that was the default when it has no
active
>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]