You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Lyallex <ly...@gmail.com> on 2009/06/11 06:43:43 UTC
Dynamic Resources: getRealPath() returns the 'wrong' path
Hi
apache-tomcat-6.0.16
jdk1.6.0_03
Dev box : Windows
Deployment box: Linux
I have my server installed at
C:\servers\tomcat\apache-tomcat-6.0.16\
My application is installed at
C:\servers\tomcat\apache-tomcat-6.0.16\webapps\ROOT
I have an image cache available at
C:\servers\tomcat\apache-tomcat-6.0.16\webapps\ROOT\imagecache
In a servlet I do the following
String pathToImagecache = getServletContext().getRealPath("imagecache");
logger.log(Level.INFO, "The path to the image cache is " + pathToImagecache);
The logging output gives the following
INFO: The path to the image cache is
C:\servers\tomcat\apache-tomcat-6.0.16\temp\1-ROOT\imagecache
I need to get hold of the imagecache directory to write images to it
but I have no idea what this \temp\1-ROOT\ bit of the path all about
???
The only way I can get the correct path at the moment is to set up an
EV in context.xml then do a JNDI lookup in my site cooker and save the
value to my config server... I'd much rather use getRealPath as I
don't have to change the config when I deploy to live.
I'm confused, any help much appreciated
lyallex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by Lyallex <ly...@gmail.com>.
2009/6/11 Mark Thomas <ma...@apache.org>:
> Lyallex wrote:
>> The logging output gives the following
>>
>> INFO: The path to the image cache is
>> C:\servers\tomcat\apache-tomcat-6.0.16\temp\1-ROOT\imagecache
>
> This is a side effect of using the anti-locking attributes on your context.
Er, OK ... thanks.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by Mark Thomas <ma...@apache.org>.
Lyallex wrote:
> The logging output gives the following
>
> INFO: The path to the image cache is
> C:\servers\tomcat\apache-tomcat-6.0.16\temp\1-ROOT\imagecache
This is a side effect of using the anti-locking attributes on your context.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Lyallex [mailto:lyallex@gmail.com]
> Subject: Re: Dynamic Resources: getRealPath() returns the 'wrong' path
>
> Works perfectly ... except I just cannot get he DefaultServlet to
> serve any images that are written to any directory anywhere on the
> filesystem after the server has started ...
Try this: create a conf/Catalina/[host]/imagecache.xml file containing a <Context> element with a docBase attribute that points to the cache file ("C:/blackhole/magecache"). Construct your image URLs like this:
http://domain.com/imagecache/[imageName].jpg (or whatever for the name and type).
This should let the DefaultServlet run under this secondary webapp and access the files you place there.
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by Lyallex <ly...@gmail.com>.
2009/6/11 Mark Thomas <ma...@apache.org>:
> Lyallex wrote:
>> 2009/6/11 Caldarale, Charles R <Ch...@unisys.com>:
>>
>>> Writing to the webapp's deployment location is a bad idea - you again have no guarantee that it's allowed, and you're at the whims of the container and execution environment controlling the actual location. Much better to write your files outside of Tomcat's directory space, using a path defined by system property, environment variable, or webapp property.
>>>
>>> - Chuck
>>
>> Yep, I tried this. I set up the following in context.xml
>>
>> <Environment name="imagecache" value="C:/blackhole/magecache"
>> type="java.lang.String" override="false"/>
>>
>> When the app starts I look up the value for the imagecache path
>>
>> imageCache = (String)ctx.lookup("java:comp/env/imagecache");
>>
>> then store it in my config server.
>>
>> When I want to write a file I get the path from the config server,
>> create a java.io.File and write the data. If I look in the blackhole
>> there are the files (images) I know it works b'cos I can open them in
>> an image editor.
>>
>> Works perfectly ... except I just cannot get he DefaultServlet to
>> serve any images that are written to any directory anywhere on the
>> filesystem after the server has started ... apologies for letting this
>> leak into this thread but I though I might need to use some Servlet
>> spec type API to write files so that the DefaultServlet could 'see'
>> them ... hence the use of getRealPath .... grasping at straws ? You
>> bet.
>
> If you use getRealPath and write them to the path it returns - ie the
> one with n-ROOT in it - then the DefaultServlet should serve them.
> You'll need to write them to the 'proper' ROOT context as well or you'll
> lose them on reload.
>
> Alternatively, you could fix whatever problem caused you to use
> anti-resource/jar locking in the first place.
>
> Mark
OK, well thanks for this it seems to be working now.
I have removed the locking attributes from the context and the images load now.
These attributes were a legacy of problems I was having with the
tomcat ant deploy task not deleting some jars. Not sure why this is no
longer an issue really. Nothing has changed in my build script ...
Still, fingers crossed it all works as planned. I still have some
tests to do, if I have more problems I'll be back .
Thanks to all those who took the time to reply, it's much appreciated
lyallex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by Mark Thomas <ma...@apache.org>.
Lyallex wrote:
> 2009/6/11 Caldarale, Charles R <Ch...@unisys.com>:
>
>> Writing to the webapp's deployment location is a bad idea - you again have no guarantee that it's allowed, and you're at the whims of the container and execution environment controlling the actual location. Much better to write your files outside of Tomcat's directory space, using a path defined by system property, environment variable, or webapp property.
>>
>> - Chuck
>
> Yep, I tried this. I set up the following in context.xml
>
> <Environment name="imagecache" value="C:/blackhole/magecache"
> type="java.lang.String" override="false"/>
>
> When the app starts I look up the value for the imagecache path
>
> imageCache = (String)ctx.lookup("java:comp/env/imagecache");
>
> then store it in my config server.
>
> When I want to write a file I get the path from the config server,
> create a java.io.File and write the data. If I look in the blackhole
> there are the files (images) I know it works b'cos I can open them in
> an image editor.
>
> Works perfectly ... except I just cannot get he DefaultServlet to
> serve any images that are written to any directory anywhere on the
> filesystem after the server has started ... apologies for letting this
> leak into this thread but I though I might need to use some Servlet
> spec type API to write files so that the DefaultServlet could 'see'
> them ... hence the use of getRealPath .... grasping at straws ? You
> bet.
If you use getRealPath and write them to the path it returns - ie the
one with n-ROOT in it - then the DefaultServlet should serve them.
You'll need to write them to the 'proper' ROOT context as well or you'll
lose them on reload.
Alternatively, you could fix whatever problem caused you to use
anti-resource/jar locking in the first place.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by Lyallex <ly...@gmail.com>.
2009/6/11 Caldarale, Charles R <Ch...@unisys.com>:
> Writing to the webapp's deployment location is a bad idea - you again have no guarantee that it's allowed, and you're at the whims of the container and execution environment controlling the actual location. Much better to write your files outside of Tomcat's directory space, using a path defined by system property, environment variable, or webapp property.
>
> - Chuck
Yep, I tried this. I set up the following in context.xml
<Environment name="imagecache" value="C:/blackhole/magecache"
type="java.lang.String" override="false"/>
When the app starts I look up the value for the imagecache path
imageCache = (String)ctx.lookup("java:comp/env/imagecache");
then store it in my config server.
When I want to write a file I get the path from the config server,
create a java.io.File and write the data. If I look in the blackhole
there are the files (images) I know it works b'cos I can open them in
an image editor.
Works perfectly ... except I just cannot get he DefaultServlet to
serve any images that are written to any directory anywhere on the
filesystem after the server has started ... apologies for letting this
leak into this thread but I though I might need to use some Servlet
spec type API to write files so that the DefaultServlet could 'see'
them ... hence the use of getRealPath .... grasping at straws ? You
bet.
Anyway, thanks for taking the time to reply
lyallex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Dynamic Resources: getRealPath() returns the 'wrong' path
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Lyallex [mailto:lyallex@gmail.com]
> Subject: Dynamic Resources: getRealPath() returns the 'wrong' path
>
> INFO: The path to the image cache is
> C:\servers\tomcat\apache-tomcat-6.0.16\temp\1-ROOT\imagecache
ServletContext.getRealPath() is one of the leftovers from the early days that probably should have been deprecated. The container is under no obligation to provide access to the underlying file system (if there is one), other than to a spec-defined temporary work area.
To access resources contained within the webapp's name space, you likely should be using getResourceAsStream(), either the ClassLoader or the ServletContext version, as appropriate.
Writing to the webapp's deployment location is a bad idea - you again have no guarantee that it's allowed, and you're at the whims of the container and execution environment controlling the actual location. Much better to write your files outside of Tomcat's directory space, using a path defined by system property, environment variable, or webapp property.
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org