Dynamic Resources: getRealPath() returns the 'wrong' path

[Lyallex]

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

[Mark Thomas]

Post by Lyallex
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

[Lyallex]

Post by Mark Thomas

Post by Lyallex
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.

Post by Mark Thomas
Mark
---------------------------------------------------------------------

[Caldarale, Charles R]

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.

[Lyallex]

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

[Caldarale, Charles R]

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:
Loading Image... (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.

[Mark Thomas]

Post by Lyallex

Post by Caldarale, Charles R
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

[Lyallex]

Post by Mark Thomas

Post by Lyallex

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

Post by Mark Thomas
---------------------------------------------------------------------