tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: SOLVED: How to get the context path for a web application?
Date Wed, 11 Aug 2004 12:50:34 GMT
Hi,
Several Tomcat committers are in touch (and for that matter, personally know) several members
of the Servlet Expert Group.

The cause for some of these specs is the fact servlet containers aren't required to run on
file systems.  For example, they may run entirely inside a DBMS (and Oracle had such a container
for a while), in which case you must deploy in a packed WAR and the subset under a server's
URL name space is not a hard-drive path.  But then again, I'm not going to bother discussing
this again, it's been done enough in the past.  If you want to change the Spec, contact the
expert group yourself, and I'm sure they'll weigh your concerns seriously.

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: Endre StĂžlsvik [mailto:Endre@Stolsvik.com]
>Sent: Wednesday, August 11, 2004 5:25 AM
>To: Tomcat Users List
>Cc: David Wall
>Subject: RE: SOLVED: How to get the context path for a web application?
>
>On Tue, 10 Aug 2004, Shapira, Yoav wrote:
>
>|
>| Hi,
>|
>| >Agreed, but my follow-up question was if there was such a call to be
>| done
>| >using a ServletContext/ServletConfig object so that you can get the
>| context
>| >path in initialization servlets, etc., before a request comes in.
>|
>| No, and an archive search would reveal past discussions around this
>| issue (though none recently).   Webapps are supposed to be independent
>| of their server configuration including with regards to context path,
>| and so the Servlet Spec actively discourages you from doing webapp
>| initialization or configuration based on such data.  A lot of people
>| debated for a long time what does and doesn't go into the
>| ServletContext/ServletConfig objects as opposed to Request/Response
>| objects.
>
>I'm jumping in on this thread, since I just had the same problem: I wanted
>to do some initing for developers on a particular setup, where I wanted to
>be able to override init (development-)settings per user per webapp w/o
>messing with any webapp-specific config files. Per user is OK, but per
>webapp is impossible.
>
>Look at this snippet from servlet JavaDocs..:
>
>[
>http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/ServletContext.
>html ]
>
>  "  There is one context per "web application" per Java Virtual Machine.
>(A "web application" is a collection of servlets and content installed
>under a specific subset of the server's URL namespace such as /catalog and
>possibly installed via a .war file.)  "
>
>Thus, there is a -clear- notion of a Webapp living under "a specific
>subset of the server's URL namespace". What is that subset, please?
>
>I find it very non-coherent and non-consistent that you can get this on a
>request, but not on startup. Now, why is that? The argument about
>"supposed to be independent" doesn't do it for me: This independence isn't
>more enforced by -taking away- the information that you nonetheless have
>to, and are, given on a request. And it encourages, as you state in a
>later mail, folks to duplicate information in config files, e.g. web.xml -
>and at that point you most definately have ripped the independence of the
>webapp to small pieces.
>
>
>If anyone here will be on the next Servlet EG, then please ask these
>questions again! I'm informed that this has had its fair share of
>discussion before - but please either remove that JavaDoc, or -gimme the
>information- via the ServletContext object!
>
>Endre.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message