Re: org.apache.fop.fo.ValidationException: fo:list-block is missing child elements
I get this error intermittently while generating PDF report using FOP 1.0.
null:5511:928: {http://www.w3.org/1999/XSL/Format}block; is not a valid
child of fo:table-row! (See position 5511:928). In most cases this issue
is resolved on resubmitting the report. Can any one pin point what is the
actual cause of this issue and why it is happening occasionally for the same
input?
org.apache.fop.fo.ValidationException: {
http://www.w3.org/1999/XSL/Format}block; is not a valid child of
fo:table-row! (See position 1143:945)
On Fri, Jul 15, 2011 at 9:42 AM, Chris Bowditch
bowditch_ch...@hotmail.comwrote:
On 12/07/2011 12:11, Glenn Adams wrote:
this is not a bug, as pointed out by Pascal
By debug I meant debug the XSLT/XSL-FO rather than the Java code.
On Tue, Jul 12, 2011 at 5:08 AM, Chris Bowditch
bowditch_ch...@hotmail.com
mailto:bowditch_chris@**hotmail.combowditch_ch...@hotmail.com
wrote:
On 12/07/2011 09:52, tecshine wrote:
Hi,
Thanks for the reply Pascal
I have tried using fopFactory.**setStrictValidation(false); but
it doesnt
solve the problem.
Our entire application was based on FOP 0.20.5 and rewriting
all XSLTs would
mean a lot of work.
Is there any other way we can resolve the issue.
Can you generate the XSL-FO and post it to the list (if its not
too big)
Since you are submitting XSLT+XML to fop you will need to use
-foout option when running FOP from the command line to generate
the intermediate XSL-FO. We can debug the issue by looking at the
XSL-FO.
Thanks,
Chris
Pascal Sancho wrote:
Hi Swetha,
FOP 1.0 is more strict than FOP 0.2x regarding the XSL-FO
REC 1.1.
Probably you will experiment further ValidationExceptions
against FO
elements or attributes (missing %block% in fo:table-cell
is the most
popular).
The best way is to rewrite your XSL-T to produce strict
XSL-FO.
But FOP team offered a configuration tip to help in FOP
0.2x to Latest
migration: see [strict-validation] element at [1].
[1]
http://xmlgraphics.apache.org/**fop/1.0/configuration.html#**
general-availablehttp://xmlgraphics.apache.org/fop/1.0/configuration.html#general-available
Le 12/07/2011 08:14, tecshine a écrit :
I have migrated from fop 0.20.5 to FOP 1.0. I get the
following exception
javax.xml.transform.**TransformerException:
org.apache.fop.fo
http://org.apache.fop.fo.**ValidationException:
fo:list-block is missing child
elements. Required content model: marker* (list-item)+
(See position
369:112)
I am aware that this kind of errors occur when the
parent is empty or
doesnt
have child elements, so check the xsl file .All
fo:list-block elements
in
the xsl file contain at least one fo:list-item
child element. Even
then I
stumble upon this exception.
Can someone help me get out of this please.
Thanks in advance
Swetha
-- Pascal
--**--
**-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
mailto:fop-users-help@**xmlgraphics.apache.orgfop-users-h...@xmlgraphics.apache.org
--**--**
-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
mailto:fop-users-help@**xmlgraphics.apache.orgfop-users-h...@xmlgraphics.apache.org
--**--**-
To unsubscribe, e-mail:
fop-users-unsubscribe@**xmlgraphics.apache.orgfop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-help@xmlgraphics.**apache.orgfop-users-h...@xmlgraphics.apache.org
--
Thanks,
Hamed Mohammed,
Email: mohdhamedms...@gmail.com.
Re: Memory Leak issue -- FOP
Hi,
This the expection I get when I try to convert XSL:FO to PDF
.
The code for creation of PDF used :
*public* *void* generatePDF(String foXml)
*throws* XMLProcessingException, SAXException
{
FOUserAgent userAgent = fopFactory.newFOUserAgent();
*try
*
{
Fop processor =
fopFactory.newFop(MimeConstants.*MIME_PDF*, userAgent,
pdfStorage.getOutputHolder());
TransformerFactory factory = TransformerFactory.*newInstance*();
Transformer transformer = factory.newTransformer(); // identity transformer
//Source src = new StreamSource(new StringReader(foXml));
Result res = *new* SAXResult(processor.getDefaultHandler());
SAXSource source = *new* SAXSource(*new* InputSource(*new*StringReader(foXml)));
source.setXMLReader(XMLReaderFactory.*createXMLReader*());
transformer.transform(source, res);
}catch
.
...
I have used eclipse memory analyzer tool to analyze the heap dumps created
as a result of the execption above.
On Wed, Sep 1, 2010 at 12:53 AM, Craig Ringer
cr...@postnewspapers.com.auwrote:
On 30/08/10 22:29, Hamed Mohammed wrote:
Hi,
This is how I am using FOP to process XSL.FO http://xsl.fo/
http://XSL.FO http://xsl.fo/ into PDF. I
agree that the issue is to do with too much of memory consumption. Is
there a better way to process this large FO file into PDF using FOP?
How much memory is too much? Have you used the JVM's tools to find out
*where* the memory is going?
If you don't know Java's profiling tools well, you might want to try the
rather user-friendly memory profiler in NetBeans. NetBeans opens Maven
projects directly, and can be set up for a generic Ant project quite
quickly, so if you're not already using it there's no reason not to just
for this.
String xml = builder.getReport(); /// gets the XSL:FO file data approx
50mb
If you're concerned about memory consumption, writing your XSL-FO to a
tempfile rather than an in-memory string and passing that to FOP's SAX
engine would be a big help. Or, for that matter, writing directly to the
SAX handler's InputStream, progressively generating the document as it's
required so it never has to exist entirely in memory or on disk.
PdfStorage pdfHolder = pdfStorageFactory.createStorage(reportRequest,
What's PdfStorage? It doesn't seem to be in fop's packages...
Any chance you can post a self-contained test program that demonstrates
the problem you describe, along with sample input for it?
--
Craig Ringer
Tech-related writing: http://soapyfrogs.blogspot.com/
--
Thanks,
Hamed Mohammed,
Email: mohdhamedms...@gmail.com.
Re: Memory Leak issue -- FOP
Hi,
This is how I am using FOP to process XSL.FO into PDF. I agree that
the issue is to do with too much of memory consumption. Is there a better
way to process this large FO file into PDF using FOP?
String xml = builder.getReport(); /// gets the XSL:FO file data approx 50mb
PdfStorage pdfHolder = pdfStorageFactory.createStorage(reportRequest,
contentType);
pdfMaker.generatePDF(pdfHolder, xml); // Instance of PdfCreator injected
through Spring.
On Mon, Aug 30, 2010 at 1:07 AM, Dominik Stadler
dominik.stad...@dynatrace.com wrote:
Hi,
Craig is right, it's it's not a memory leak, but rather memory kept
active too long, i.e. after processing is done. I saw the same thing when I
integrated FOP into an application over here.
It is basically caused by the SAX implementation that you use as it caches
the SAX-Handler, where the FOP-SAX-Handler keeps references to a lot of
internal stuff. In my case it did this in a ThreadLocal, so with different
threads using FOP I ended up having this memory kept in every thread, which
accumulated to quite an amount of memory depending on the usage pattern.
I tried various different ways to solve this, when using SAX/XML provided
as part of Sun JDK 1.6 the following was removing this memory bloat:
Result result = new SAXResult(fop.getDefaultHandler());
SAXSource source = new SAXSource(inputSource);
// set our own XMLReader to prevent Sun XML from caching
stuff in ThreadLocals which keeps FOP in memory
// we want to free up any FOP resources when not reporting
and for this ThreadLocals is very bad, especially
// as we are called in different threads via REST and
Scheduling thread pools!
source.setXMLReader(XMLReaderFactory.createXMLReader());
transformer.transform(source, result);
if (logger.isLoggable(Level.FINE) fop.getResults() !=
null) {
logger.info(Processing resulted in +
fop.getResults().getPageCount() + pages.); //$NON-NLS-1$ //$NON-NLS-2$
}
}
Maybe a similar thing solves this for you as well.
Dominik.
-Original Message-
From: Craig Ringer [mailto:cr...@postnewspapers.com.au]
Sent: Donnerstag, 26. August 2010 02:35
To: fop-users@xmlgraphics.apache.org
Cc: Hamed Mohammed
Subject: Re: Memory Leak issue -- FOP
On 26/08/2010 3:39 AM, Hamed Mohammed wrote:
Hello Users:
Any idea on how to solve the FOP memory leak issue. Below snap shots are
taken from Eclipse Memory Analyzer of a IBM portable heap dump.
What makes you think that's a memory leak?
It's a large amount of memory consumption, sure. But is there any
evidence it's growing over time? Or growing whenever a new document is
processed, without shinking again when the document is finished?
How do you know it's not your own code keeping references to the fop
instances around? Can you produce a small, self-contained program that
demonstrates the leak?
If your real question is why is FOP using so much memory ... well, to
answer that it'd be necessary to know more about your XSL-FO input and
the associated resources like graphics.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
--
Thanks,
Hamed Mohammed,
Email: mohdhamedms...@gmail.com.
