tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject RE: Retrieving the context path from a standalone class
Date Thu, 08 Jan 2004 05:29:10 GMT

Just to contribute to delinquency, here's a couple ways to obtain the 
context path at runtime from the ServletContext....

One way is by taking advantage of Tomcat's naming conventions with the 

         String tempdir =
           "" + context.getAttribute("javax.servlet.context.tempdir");
         int lastSlash = tempdir.lastIndexOf(File.separator);

         if ((tempdir.length() - 1) > lastSlash) {
           logHomePropName = tempdir.substring(lastSlash + 1) + ".log.home";

Another, which is more (fully?) server agnostic is...

           //use a more standard way to obtain the context path name
           //which should work across all servers.  The tmpdir technique
           //(above) depends upon the naming scheme that Tomcat uses.
           String path = context.getResource("/").getPath();

           //first remove trailing slash, then take what's left over
           //which should be the context path less the preceeding
           //slash such as "MyContext"
           contextPath = path.substring(0, path.lastIndexOf("/"));
           contextPath =
             contextPath.substring(contextPath.lastIndexOf("/") + 1);

I use that to create an environment variable based on the name of the 
context because I can reference this predictable and unique name in my 
log4j properties file without having to specify it multiple places and have 
to remember to update it all the time...

          logHomePropName = contextPath + ".log.home";


At 02:34 PM 1/7/2004 -0500, you wrote:

> >Will it's inclusion encourage programmers to
> >start building bad apps (no, I think.)
>FYI, aside from the issue of developer versus deployer, I strongly
>disagree with the above: adding anything that encourages bad practices
>is a bad idea.  It'll be like another ServletRequest#getRealPath call,
>which has been a disaster for years now.  Thankfully it was deprecated
>as soon as possible in version 2.1 of the spec, but still it haunts us
>and it has caused many bad implementations.
>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:

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

View raw message