2012/8/25 Mark Eggers <its_toas...@yahoo.com>:
> Folks,
>
> This is not strictly a Tomcat problem, but since the application is running
> under Tomcat I thought I would ask.
>
> Environment
> -----------
> Tomcat: 6.0.20
> JRE: 1.6.0_16
> OS: some UNIX variant
>
> I'm a little light on the environment, since it's not mine. Yes, this is
> old. No, I don't have any leverage to get them to update.
>
> Background
> ----------
>
> An application makes use of a PDF library which generates PDFs from JSP
> pages. One of these pages includes a dynamically generated graph.
>
> This library cannot use streaming data to include the graph. The only two
> options are:
>
> 1. Write the graph within the web application and use relative paths
> 2. Write the graph somewhere else and:
> a. use a fully qualified URL point to a servlet
> b. the servlet retrieves the graph by name
>
> Ideally, we write the JPG file to java.io.tmpdir, then reference a servlet
> in the JSP to fetch the graph and insert it into the page.
>
> Considerations
> --------------
>
> Unfortunately, in certain environments we cannot use solution 2. One of
> these environments involves a NAT and hairpinning. In those cases, we use
> solution 1.
>
> We use getRealPath in a listener, tag on a directory to write images, set
> the path in a singleton, and we're done. We can then use a relative
> directory in the JSP to get the image and generate the PDF.
>
> If for any reason getRealPath returns a null, we fall back to using
> java.io.tmpdir.
>
>
> Problem
> -------
>
> I ran into a situation where getRealPath with the above environment returns
> a null, even when the WAR file is exploded.
>
> This means that we fall back to java.io.tmpdir, and run into the hairpinning
> problem.
>
> Question
> --------
>
> What other reasons could there be for getRealPath to return a null rather
> than the path where the application is run?
>
> Some other Info
> ---------------
>
> They are not running under a security manager. ps shows no security manager
> arguments, and at any rate the application would throw a bunch of other
> security violations and fail to start (a few getReourceAsStream issues in
> listeners).
>
> I noticed that the server appears to be running from an NFS mount. However,
> the exploded WAR file directory is marked as 755, and the ownership is
> correct.
>
> About the only thing that comes to mind is NSF3 / NSF4 ACLs. I won't know
> more about the server environment until Monday.
>
> If anyone has ideas, I'd be happy to hear about them.
>
1. One known case is that getRealPath() will return null if the path
does not actually exist.
(In that case getResource() will return null as well).
Does getRealPath("/") work?
2. If you are guessing on ACL... can you try whether
new File(System.getProperty("catalina.base")).getCanonicalPath()
call succeeds?
I think that I heard that getCanonicalPath() can fail if some parent
directories do not have enough permissions on them.
============
3. What is your hairpinning problem?
Is it because you use "a fully qualified URL point to a servlet" and
you cannot build that URL correctly?
Do you really need an absolute URL? You mean that you cannot call your
servlet otherwise?
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
