tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: ServletContext.getRealPath(string)
Date Wed, 07 Feb 2001 17:39:57 GMT
Jason van Zyl wrote:

> Hi,
> In Turbine I wanted to provide an easy way to give
> all classes in a webapp easy access to the real
> path to the webapp: someone on the Turbine list
> mentioned that ServletContext.getRealPath(path)
> is not required to be implemented. If this is
> the case what is the best way to provide access
> to the webapp path.

Implementing getRealPath() is required, but it is allowed to return
null.  Consider that a container might run the web application directly
out of a WAR file (Tomcat 4.0 can do this), or by storing the static
resources as BLOB objects in a database.  In such a case, there is no
such thing as "the real path to the webapp" because it is not stored in

> In my particular case I am uploading files into
> a directory in the webapp, so I need to create
> files.
> Craig, do you have some standard of providing
> access to the webapp in Struts? Maybe I can
> borrow your idea if you're implementing something
> like this.

For Struts, we use ServletContext.getResource() for read access to webapp
resources, so it does not matter whether or not getRealPath() returns
null.  For writeable things (like file uploads), the normal pattern is a
servlet initialization parameter that defines the upload directory.  You
could make this default intelligently by trying to call
getRealPath("/upload/dir") and using that value if it is non-null.

If you are uploading things that need to become part of the webapp (like
a new Velocity template installed on the fly), you will probably need to
add restrictions in your deployment instructions that it will only work
on a servlet container that unpacks the webapp to a directory structure.

Providing portable APIs for writeable resources was discussed by the
expert group for 2.3, but no consensus was gained in time to make the
spec :-(.  This will undoubtedly be a high priority issue for the next

> Thanks.
> jvz.


View raw message