Lyallex wrote:
> 2009/6/11 Caldarale, Charles R <chuck.caldar...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
