RE: Path issues
> From: Thom Hehl [mailto:[EMAIL PROTECTED] > Subject: Re: Path issues > > I think, though, that tomcat should be consistent in the way > it handles things. Tomcat on Unix should behave like tomcat > under windows. Inconsistency is a real problem here. No, dependency on any behavior not defined in the spec is the problem. Your code should be doing something like: Thread.currentThread().getContextClassLoader().getResource() to access information stored with your webapp. (Note that this is read-only access - your app may not assume its location is writeable.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Path issues
I think, though, that tomcat should be consistent in the way it handles
things. Tomcat on Unix should behave like tomcat under windows.
Inconsistency is a real problem here.
Wendy Smoak wrote:
On 1/14/06, Thom Hehl <[EMAIL PROTECTED]> wrote:
Wanted to run this by the list before turning this in as a bug.
I'm running the following servlet fragment...
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
File path=new File("./");
System.out.println(path.getAbsolutePath());
When I run this under windows, the path points to the Tomcat5.5, which
is where tomcat is installed. When I run this under Redhat Linux, it
points to the webapps directory under the tomcat directory. Is there
anyone that doesn't think this is broken?
Me. :) The only thing the Servlet container is required to do for you
is provide a temporary working directory. Servlet 2.4 Specification:
"SRV.3.7.1 Temporary Working Directories
A temporary storage directory is required for each servlet context. Servlet
containers must provide a private temporary directory for each servlet
context, and
make it available via the javax.servlet.context.tempdir context attribute. The
objects associated with the attribute must be of type java.io.File."
Depending on what you're going to do with the File, if the temporary
directory won't work, several things may be more appropriate. A
database, or configuring a context param with a known good location to
which the user running Tomcat has permission to write, for example.
HTH,
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thom Hehl
Heavyweight Software for Heavyweight Needs
www.heavyweightsoftware.com
--
"In every revolution, there is one man with a vision."--Jerome Bixby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Path issues
On 1/14/06, Thom Hehl <[EMAIL PROTECTED]> wrote:
> Wanted to run this by the list before turning this in as a bug.
>
> I'm running the following servlet fragment...
> public void doGet(HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException
> {
> File path=new File("./");
> System.out.println(path.getAbsolutePath());
>
> When I run this under windows, the path points to the Tomcat5.5, which
> is where tomcat is installed. When I run this under Redhat Linux, it
> points to the webapps directory under the tomcat directory. Is there
> anyone that doesn't think this is broken?
Me. :) The only thing the Servlet container is required to do for you
is provide a temporary working directory. Servlet 2.4 Specification:
"SRV.3.7.1 Temporary Working Directories
A temporary storage directory is required for each servlet context. Servlet
containers must provide a private temporary directory for each servlet
context, and
make it available via the javax.servlet.context.tempdir context attribute. The
objects associated with the attribute must be of type java.io.File."
Depending on what you're going to do with the File, if the temporary
directory won't work, several things may be more appropriate. A
database, or configuring a context param with a known good location to
which the user running Tomcat has permission to write, for example.
HTH,
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
