2009/6/11 Mark Thomas <ma...@apache.org>:
> 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
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-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
