On 8/25/2012 12:19 PM, Konstantin Kolinko wrote:
2012/8/25 Mark Eggers <its_toas...@yahoo.com>:
On 8/25/2012 5:01 AM, Konstantin Kolinko wrote:
That PDF-generating library - where it sits? Is it on Server?
It sits in the application. It's actually two jar files - one that does the
PDF translation proper and the other is a tag library.
How does the library get its source data (an XSL-FO document?) that is
converted to PDF? Which of the following:
This I don't know, but I suspect not. The library is obfuscated, but there
doesn't appear to be the standard XSL-FO translation.
a) It uses HTTP to request a JSP page. Then it uses HTTP to request the
image.
This is the way I think it operates when you use a tag library. Why the
library requires a relative URL or a fully qualified URL but does not work
with an absolute URL I do not know.
A tag can easily get its content as a String or as a Reader.
E.g. see attributes in <jsp:doBody/> and <jsp:invoke/> standard
actions, JspFragment.invoke(Writer), BodyContent.getReader(),
BodyContent.getString().
A tag also has access to the request object and to the servlet
context, so it can use those to create an URL, or it uses
ServletContext.getResource[AsStream]() to get the file.
A debugger + a breakpoint in URL.openConnection() or in
ServletContext.getResource(), or in some java.io classes can tell how
the data are loaded. (Or just ask the library authors).
I'd love to ask the library authors. Sadly, they seem less than
responsive. I sent them a small web application that creates the permgen
leak (happens any time an image is included) several weeks ago, and no
response so far.
I'll ping them again today.
(...)
Hmm, I think I tried UrlRewriteFilter before, but maybe not in quite the
right way. You are thinking along the lines of rewriting
http://some-host:80/context/servlet?name=imagename
to
../servlet-location/servlet?name=imagename
and letting the servlet dig it out of java.io.tmpdir?
I was thinking about naming the images in some specific way and using
that to forward requests to the servlet, regardless of actual path.
I actually have the file name. I can pass it as a parameter to the
servlet getting the image, send that off to a POJO to figure out where
the image actually is, return a BufferedImage, and send that out.
On second thought, it might be even easier to just use suffix matching
in web.xml.
E.g. if the images are named *.dynamic.png and the servlet (or filter)
is mapped like
<servlet-mapping>
<url-pattern>*.dynamic.png</url-pattern>
and then the servlet can ignore all the path except the file name.
Ah, and I wish there was a regular expression I could map to file names.
The file names are (currently) some arbitrary number followed by an
underscore, followed by the session id (?!) followed by .jpg.
I didn't write this . . . I'm just the poor systems architect who gets
to make stuff work. I'm not really a Java developer. I do enough
development to get myself in trouble, and that's about it.
BTW, if it were Tomcat 7 (and not 6.0.20) you would also have an
option of using <Context aliases="..." /> to map the temporary folder
into some subdirectory of your web application.
Lots of nice things in Tomcat 7. I doubt that the target environment
will move to that any time soon.
Per your and Terence's suggestion, I just tried a file:/// URL on my
local platform.
I replaced the img src="servlet-url" with:
file:///c:/Users/mdeggers/Apache/apache-tomcat-6.0.35/temp/gf-title-sm.jpg
since I'm doing this on a Windows 7 machine right now.
I got images embedded in the PDF.
I'm guessing (as you apparently did, Konstantin) that the library
creates a URL from the string, then does an openConnection() (or maybe
an openStream()).
I am sure glad this isn't running under a security manager.
I'll make some changes in my copy of the application, and run it on the
test server. It's easy enough to construct a string, stuff it into a
singleton via a listener, then have that resource available everywhere
it's needed in the application.
I won't know if this is the final solution until at least Monday, but I
can reproduce most of this (hairpinning at least) on a test environment.
Thanks to all - I'll post a followup when I get feedback from the people
running the target environment.
. . . . thanks again
/mde/
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
