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]
RE: Rooting request to one or an other webapp
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]
Rooting request to one or an other webapp
Hi, 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. Marc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
