xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Need immediate help.. FOP on Solaris Box
Date Mon, 07 Apr 2008 12:58:01 GMT

On 07.04.2008 12:04:56 Newkid wrote:
> 
> Hello Pietschmann,
> 
> Thanks for your explainations.
> 
> Let me allow to brief the case history:
> 
> I have complex Java application deployed on Weblogic 8.1 SP6. There is a
> requirement to create PDF /RTF from the XML file. When a user creates XML
> file, the file is getting stored in the ORACLE database as CLOB object.
> There is NO problem in creating a PDF/RTF of corresponding valid XML file
> and store it outside the web directory. The problem is, how do I create a
> PDF/RTF and XML files in the EAR file dynamically. By all mean, I am unable
> to find out creating / reading the files from the deployed EAR in the
> weblogic. 
> 
> In order to get rid of the situation, I thought to take a other way to
> resolve this concern i.e. streaming the files and displaying directly on the
> browser. By doing this, I can resolve the reading/ creating files on the
> deployed EAR on weblogic. Now, the million dollar questions for me is
> HOW????? I have NO idea whether FOP does support streaming or not? If it
> does, I can move forward else I have to look for some other way...

I'm afraid I have to tell you that FOP is not the all-doing
uber-application that can do everything. It shouldn't, actually. FOP
doesn't care where the XSL-FO input document comes from, it just expects
a SAX stream (see the pointers below). And FOP doesn't care where its
output is sent to, it just writes it to an OutputStream. Feeding FOP
with the XSL-FO is your job, just as sending the generated PDF/RTF file
to the browser is.

Apache Cocoon is more like an application that does the whole
integration between database and browser. But since you seem to be under
time constraints this is not an option as Cocoon is not that simple to
use. But Cocoon would be ideal for this sort of thing. FOP is just a
little component inside Cocoon.

> Further more, there is NO problem in the reading the XML file from database
> as string. The problem is, can FOP convert the xml using XSL byte by byte???
> Can FOP take XML file as STRING and generate PDF as STRING? Since, there is
> NO change in the XSL file, I can keep it the web directory easily. If yes,
> how? I need the guidance and your precious advice.

That already sounds pretty good. I would like to point you to the
following page: http://xmlgraphics.apache.org/fop/stable/embedding.html#examples

This is a step-by-step tutorial/example that shows you how to integrate
various steps in a conversion pipeline. The XML you get from the
database is equivalent to the "ProjectTeam" Java object in the example.
If you go through the example you learn how you can use JAXP/TraX to
convert an XML stream from any source into XSL-FO that is fed to FOP.

For your case (you said you already have a String with the XML), you can
use the following as input source for the XSL transformation:

[..]
String myxml = getXMLFromDatabase();
Source src = new StreamSource(new StringReader(myxml));
Result res = new StreamResult(........
transformer.transform(src, res);
[..]

> Since, I have to deploy the application on Solaris box and I am using SHELL
> SCRIPT, I did mention about the Solaris...

Ok, here's where my hairs stand up, unfortunately. I hope you're only
using a shell script to deploy the application, not to call FOP. A shell
script inside an application server? If that is the case here, there's
something really wrong as a new JVM is spawned each time a document is
converted. This is slow and would break the J2EE specification if not
done in exactly the right way. Please integrate FOP properly into the
application. Do not call shell scripts to call another Java application
from inside a Java application. Of course, when you're inside a EJB
context, just calling FOP may still break the J2EE specification if
local files are used. Instead make sure you can access all resources via
(non-file) URIs/URLs if working from within an EJB context.

Please note that similar concerns as stated by Joerg exist on my side.
You gave us a much better picture now which allows us to give you better
answers. I'm still not sure, however, if I've hit the nail on the head.

Good luck!

> Once again, thanks for showing some lights on my concern!
> 
> Warm Regards,
> Newkid
> 
> 
> J.Pietschmann wrote:
> > 
> > Technically: yes for both questions.  However, this is based
> > on a woefully broad set of assumptions on what you probably
> > mean. Which is, based on experience with this kind of questions,
> > slightly different from what you actually mean.
> > Ok, the assumptions are:
> > - You develop a web application based on Java servlets
> > - For question a, you want to read an XML document from a
> >    servlet input stream, transform it using an XSL style sheet
> >    read from a file belonging to the web application, render
> >    the result to PDF and store it as a file somewhere else.
> > - For question b, you read a complete XML document from the
> >    database, transform/render it and send to the servlet's
> >    output stream.
> > 
> > Usually, follow-up questions include
> > - How do I get the XSL transformation? Possible answers:
> >    Either put in a jar in the lib directory (i.e. on the
> >    classpath) and load it as a resource, or put it into the
> >    content area and try to use getRealPath to resolve the
> >    file system path. Both methods have drawbacks.
> > - How do I get the XML from the database into the transformation?
> >    Answer: ask someone how the get it as a string, then use a
> >    StringSource.
> > - Why doesn't FOP like the XML read from the database? Answer:
> >    It's the XML parser which barfs for a variety of possible reasons:
> >     - you didn't store a proper XML document in the database field
> >     - the database mangled the character encoding
> >     - the XML was double escaped by an automatism which tried to
> >       be helpful, but wasn't
> >     - your server runs an old Java version and your XML triggered a
> >       known bug in the parser included in the JRE.
> > - Why doesn't the browser show the PDF? Actually, the question should
> >    be: How do I debug this? Answer: develop and test each step
> >    separately. Develop the transformation outside of the web
> >    application. Make sure you get the same XML out of the database
> >    which you put in. Put only everything together and in the web
> >    application once you are sure every step works. Don't do "small
> >    fixes" for the XSL transformation in the web application
> >    environment, develop it in the external environment, run the
> >    automated regression tests (you write automated regression
> >    tests, do you?), then deploy it.
> > 
> > I still wonder where the "solaris box" factlet fits in.
> > 
> > J.Pietschmann
> > 
> 
> -- 
> View this message in context: http://www.nabble.com/Need-immediate-help..-FOP-on-Solaris-Box-tp16508410p16537206.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org



Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message