Thanks a lot! We do have a configuration decision based on a term, we call it *context path* in the database. We use it to uniquely identify a web application. Through this discussion, we could call it whatever as long as it helps us to find information about a particular web application in the database. Using a context init parameter to initialize the term is the way to go.
Jing ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Jing Zhou" <[EMAIL PROTECTED]> Cc: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, July 31, 2003 2:51 PM Subject: Re: Could one figure out the context path in Servlet.init() method? > > > On Thu, 31 Jul 2003, Jing Zhou wrote: > > > Date: Thu, 31 Jul 2003 13:17:39 -0500 > > From: Jing Zhou <[EMAIL PROTECTED]> > > To: Craig R. McClanahan <[EMAIL PROTECTED]>, > > Struts Users Mailing List <[EMAIL PROTECTED]> > > Subject: Re: Could one figure out the context path in Servlet.init() > > method? > > > > I see. I looked through the Servlet Spec 2.3 and no restrictions > > are found to have multiple context paths mapped to one web > > application. But how such capability is utilized in a servlet > > container? I do not find information on how to map multiple > > context paths to one web application. Is this container vendor > > specific thing? > > > > Since it is not a spec thing, container support for this feature would > definitely be container specific, as would configuration. > > Tomcat, for example, does not support it directly for context paths (you > can point two <Context> elements at the same directory, but you get two > different webapp instances), but it does allow an app to have multiple > hostnames, courtesy of the fact that you can have an <Alias> directive for > the owning <Host>. This is mostly used so that things like the following > two URLs: > > http://www.mycompany.com/myapp/ > > http://mycompany.com/myapp/ > > resolve to the same webapp. But the principle is the same -- it would not > be reasonable for a servlet's init() method to ask "what is my server > name?", because there is more than one. > > > Another thought that is surprising me is that a web application > > could not assume its context paths are *constants* in the > > application life cycle. Is this assumption valid in general? > > (Of course one should not change context paths very often > > even if they could be changed.) > > Again server dependent, especially on servers where you can dynamically > install and remove alias directives. > > Portably written applications should make no assumptions about what > context path they are executing under - that decision should be up to the > person installing the app instead. That's why, for example, Struts tags > and methods all focus on context-relative paths; they work no matter what > the context path is. If you've got configuration decisions to make based > on what the actual context path is (as it sounds like you do), it might be > better to externalize that stuff into a separate context init parameter, > which therefore would be available at startup. > > > > > Jing > > Craig > > > > > > ----- Original Message ----- > > From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Jing > > Zhou" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Thursday, July 31, 2003 10:57 AM > > Subject: Re: Could one figure out the context path in Servlet.init() method? > > > > > > > > > > > > > On Thu, 31 Jul 2003, Jing Zhou wrote: > > > > > > > > > > > I am wondering if there is a way to get the context path without > > > > using init parameters during the initialization of a servlet. > > > > Any clues? We have ServletContext.getRealPath(), but not > > > > the ServletContext.getContextPath(). Why can't the ServletContext > > > > tell me its context path? > > > > > > > > > > You are assuming that a web applicaton only has one context path. That > > > does not have to be the case. > > > > > > > Jing > > > > > > Craig > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
