Qiao Jin wrote:
> Chuck, thanks for your response. It turns out that the auto-deploy switch
> does affect the situation. New subdirs created after the auto-deploy is
> turned off are no longer being treated as separate apps and getRealPath is
> returning the path as I expected.

This looks very much like you have configured appBase == docBase for the ROOT
web application. This is likely to cause a world of pain - the behaviour you
have seen here being just one example. Try restarting Tomcat and see what
happens to your getRealPath() calls...

docBase should never be set to the same location as appBase.

Mark


> 
> ServletContext.getResourceAsStream() is fine for accessing a file. In my
> case, I need to list all the files under an image directory. Here is my
> directory structure:
> 
> Approot/sub1/test.jsp
> Approot/sub1/images/{image files}
> 
> test.jsp needs to present a list of all images in the sub1 dir, thus it
> needs a File object representing "images". I tried to use
> ServletContext.getResource("/sub1/images"), the resultant URL was converted
> to an URI with .toURI() and fed to 'new File()'. It didn't work. File(URI)
> requires an URI with the "file" scheme. 
> 
> 
> Qiao
> 
> -----Original Message-----
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
> Sent: Friday, January 30, 2009 12:09 PM
> To: Tomcat Users List
> Subject: RE: application.getRealPath() in JSP from a subdirectory
> 
>> From: Qiao Jin [mailto:bra...@gmail.com]
>> Subject: application.getRealPath() in JSP from a subdirectory
>>
>> I am using Tomcat 6.0.18, JDK 1.5 on CentOS 5. From within a JSP page,
>> applicaton.getRealPath() is returning results that I wasn't expecting.
> 
> Using getRealPath() inside an app server of any kind is pretty much always a
> Bad Idea.  If you need to access a file from your webapp, use
> ServletContext.getResourceAsStream().  If you need a place to store a file,
> it certainly shouldn't be inside the webapp deployment area, which should be
> treated as read-only.
> 
>  - 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: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to