Help - Screen Widgets and FOP

[Adrian Crum]

I'm having trouble using the ScreenFop view handler.

I'm trying to get the Entity Reference Chart to output to PDF. I created a Freemarker template that
generates the correct output. I set up a view handler:

<view-map name="entityrefReport" type="screenfop"
page="component://webtools/widget/EntityScreens.xml#EntityRefReport" content-type="application/pdf"
encoding="none"/>

When I access that view, the hourglass cursor appears indefinitely. Many debug.log files are
generated - totalling over a GB. After waiting 15 or 20 minutes, I close the browser window, but the
rendering process continues. I have to shut down OFBiz to get it to stop. The debug logs just
contain informational messages - no errors. No errors in the console log either.

I know the template is generating correct FO output because I can switch to this view handler:

<view-map name="entityrefReport" type="screen"
page="component://webtools/widget/EntityScreens.xml#EntityRefReport"/>

and the template's FO output appears in the screen. If I save the browser's page source to a file, I
can convert it manually using the command-line FOP and it creates a perfect (1000+ page) PDF file.
The entire process takes less than a minute.

So, the individual elements all work fine, but for some reason the screenfop view handler gets hung up.

Any ideas?

-Adrian

[Jacopo Cappellato]

This pretty much seems an issue with memory usage.
You could try to use an asynch service call to schedule/submit the
service call to create the PDF in the runtime/output folder: I've
implemented a generic service for this some time ago (but I don't
remember the name right now). If you are interested and you can't find
it... let me know and I will research and provide you more information.

Jacopo


Adrian Crum wrote:

> I'm having trouble using the ScreenFop view handler.
>
> I'm trying to get the Entity Reference Chart to output to PDF. I created
> a Freemarker template that generates the correct output. I set up a view
> handler:
>
> <view-map name="entityrefReport" type="screenfop"
> page="component://webtools/widget/EntityScreens.xml#EntityRefReport"
> content-type="application/pdf" encoding="none"/>
>
> When I access that view, the hourglass cursor appears indefinitely. Many
> debug.log files are generated - totalling over a GB. After waiting 15 or
> 20 minutes, I close the browser window, but the rendering process
> continues. I have to shut down OFBiz to get it to stop. The debug logs
> just contain informational messages - no errors. No errors in the
> console log either.
>
> I know the template is generating correct FO output because I can switch
> to this view handler:
>
> <view-map name="entityrefReport" type="screen"
> page="component://webtools/widget/EntityScreens.xml#EntityRefReport"/>
>
> and the template's FO output appears in the screen. If I save the
> browser's page source to a file, I can convert it manually using the
> command-line FOP and it creates a perfect (1000+ page) PDF file. The
> entire process takes less than a minute.
>
> So, the individual elements all work fine, but for some reason the
> screenfop view handler gets hung up.
>
> Any ideas?
>
> -Adrian
>

[Christian Geisert]

Adrian Crum schrieb:
> I'm having trouble using the ScreenFop view handler.
>
> I'm trying to get the Entity Reference Chart to output to PDF. I created
> a Freemarker template that generates the correct output. I set up a view
> handler:

[..]

> So, the individual elements all work fine, but for some reason the
> screenfop view handler gets hung up.
>
> Any ideas?

Sounds like a memory issue
(See http://xmlgraphics.apache.org/fop/trunk/running.html#memory for
some info on how to fix this)

If you send me a patch (or commit it) I'll be happy to have a look at it

--
Christian

[Adrian Crum]

Jacopo and Christian,

Thank you very much for your tips! I have already explored the Apache FOP website and read the
information about memory.

Here is what I have done so far:

I confirmed the code in the ScreenFop view handler is correct - it's nearly an exact copy of the
recommended code from the FOP website. I increased memory - min 512MB, max 1024MB (2 GB RAM in PC).
I re-wrote the view handler to render to a temporary file instead of a String. I used buffered
streams wherever possible. After all of that, nothing has changed. My next step is to reverse
engineer the command line FOP to see how it does things - maybe I can spot a difference between it
and the embedded code.

To restate the problem: the FO xml file is about 13MB in size and converts to a 3MB PDF file in a
few seconds using command-line FOP. When the same xml file is converted in OFBiz it runs for over an
hour until I finally shut it down - no PDF file is produced.

-Adrian


Christian Geisert wrote:

> Adrian Crum schrieb:
>
>>I'm having trouble using the ScreenFop view handler.
>>
>>I'm trying to get the Entity Reference Chart to output to PDF. I created
>>a Freemarker template that generates the correct output. I set up a view
>>handler:
>
>
> [..]
>
>
>>So, the individual elements all work fine, but for some reason the
>>screenfop view handler gets hung up.
>>
>>Any ideas?
>
>
> Sounds like a memory issue
> (See http://xmlgraphics.apache.org/fop/trunk/running.html#memory for
> some info on how to fix this)
>
> If you send me a patch (or commit it) I'll be happy to have a look at it
>

[Jacopo Cappellato]

*Maybe* it is related to the version of the parsers used (that are
determined at runtime)... for example I've noticed that in the FOP
distribution there is a Apache Xalan-J (JAXP-compliant XSLT and XPath
implementation), but not in OFBiz, and so I guess we are using the
default JAXP implementation delivered by the JDK.

But I could be totally wrong...

Jacopo


Adrian Crum wrote:

> Jacopo and Christian,
>
> Thank you very much for your tips! I have already explored the Apache
> FOP website and read the information about memory.
>
> Here is what I have done so far:
>
> I confirmed the code in the ScreenFop view handler is correct - it's
> nearly an exact copy of the recommended code from the FOP website. I
> increased memory - min 512MB, max 1024MB (2 GB RAM in PC). I re-wrote
> the view handler to render to a temporary file instead of a String. I
> used buffered streams wherever possible. After all of that, nothing has
> changed. My next step is to reverse engineer the command line FOP to see
> how it does things - maybe I can spot a difference between it and the
> embedded code.
>
> To restate the problem: the FO xml file is about 13MB in size and
> converts to a 3MB PDF file in a few seconds using command-line FOP. When
> the same xml file is converted in OFBiz it runs for over an hour until I
> finally shut it down - no PDF file is produced.
>
> -Adrian
>
>
> Christian Geisert wrote:
>> Adrian Crum schrieb:
>>
>>> I'm having trouble using the ScreenFop view handler.
>>>
>>> I'm trying to get the Entity Reference Chart to output to PDF. I created
>>> a Freemarker template that generates the correct output. I set up a view
>>> handler:
>>
>>
>> [..]
>>
>>
>>> So, the individual elements all work fine, but for some reason the
>>> screenfop view handler gets hung up.
>>>
>>> Any ideas?
>>
>>
>> Sounds like a memory issue
>> (See http://xmlgraphics.apache.org/fop/trunk/running.html#memory for
>> some info on how to fix this)
>>
>> If you send me a patch (or commit it) I'll be happy to have a look at it
>>

[Adrian Crum]

Jacopo,

Thanks for the tip! I'll check into that. Btw, thank you for updating the fop jar. I had tried that
on my local copy to see if it made a difference, but nothing changed speed-wise. It helped reduce
warning messages though.

-Adrian

Jacopo Cappellato wrote:

> *Maybe* it is related to the version of the parsers used (that are
> determined at runtime)... for example I've noticed that in the FOP
> distribution there is a Apache Xalan-J (JAXP-compliant XSLT and XPath
> implementation), but not in OFBiz, and so I guess we are using the
> default JAXP implementation delivered by the JDK.
>
> But I could be totally wrong...
>
> Jacopo
>
>
> Adrian Crum wrote:
>
>> Jacopo and Christian,
>>
>> Thank you very much for your tips! I have already explored the Apache
>> FOP website and read the information about memory.
>>
>> Here is what I have done so far:
>>
>> I confirmed the code in the ScreenFop view handler is correct - it's
>> nearly an exact copy of the recommended code from the FOP website. I
>> increased memory - min 512MB, max 1024MB (2 GB RAM in PC). I re-wrote
>> the view handler to render to a temporary file instead of a String. I
>> used buffered streams wherever possible. After all of that, nothing
>> has changed. My next step is to reverse engineer the command line FOP
>> to see how it does things - maybe I can spot a difference between it
>> and the embedded code.
>>
>> To restate the problem: the FO xml file is about 13MB in size and
>> converts to a 3MB PDF file in a few seconds using command-line FOP.
>> When the same xml file is converted in OFBiz it runs for over an hour
>> until I finally shut it down - no PDF file is produced.
>>
>> -Adrian
>>
>>
>> Christian Geisert wrote:
>>
>>> Adrian Crum schrieb:
>>>
>>>> I'm having trouble using the ScreenFop view handler.
>>>>
>>>> I'm trying to get the Entity Reference Chart to output to PDF. I
>>>> created
>>>> a Freemarker template that generates the correct output. I set up a
>>>> view
>>>> handler:
>>>
>>>
>>>
>>> [..]
>>>
>>>
>>>> So, the individual elements all work fine, but for some reason the
>>>> screenfop view handler gets hung up.
>>>>
>>>> Any ideas?
>>>
>>>
>>>
>>> Sounds like a memory issue
>>> (See http://xmlgraphics.apache.org/fop/trunk/running.html#memory for
>>> some info on how to fix this)
>>>
>>> If you send me a patch (or commit it) I'll be happy to have a look at it
>>>
>
>

[Christian Geisert]

Jacopo Cappellato schrieb:
> *Maybe* it is related to the version of the parsers used (that are
> determined at runtime)... for example I've noticed that in the FOP
> distribution there is a Apache Xalan-J (JAXP-compliant XSLT and XPath
> implementation), but not in OFBiz, and so I guess we are using the
> default JAXP implementation delivered by the JDK.
>
> But I could be totally wrong...

Yes & no ;-)
Xalan in the FOP distribution is only used when running with Java 1.3
From Java 1.4 on the jdk version is used unless you put another version
into the endorsed directory.

But this is all speculation ... as already said: show us the code,
Adrian ;-)

--
Christian

[Adrian Crum]

Christian and Jacopo,

https://issues.apache.org/jira/browse/OFBIZ-1401

Have at it! ;-)

-Adrian

Christian Geisert wrote:

> Jacopo Cappellato schrieb:
>
>>*Maybe* it is related to the version of the parsers used (that are
>>determined at runtime)... for example I've noticed that in the FOP
>>distribution there is a Apache Xalan-J (JAXP-compliant XSLT and XPath
>>implementation), but not in OFBiz, and so I guess we are using the
>>default JAXP implementation delivered by the JDK.
>>
>>But I could be totally wrong...
>
>
> Yes & no ;-)
> Xalan in the FOP distribution is only used when running with Java 1.3
>>From Java 1.4 on the jdk version is used unless you put another version
> into the endorsed directory.
>
> But this is all speculation ... as already said: show us the code,
> Adrian ;-)
>