Forcing Xerces/Xalan parsers in JVM

[Jeff Vannest]

I've embedded FOP 0.93 in an Oracle AS 10g (9.0.4) Reports pluggable
destination, which itself is implemented as a J2EE application. Therefore,
FOP is called as part of the already-running J2EE environment.

The problem that I'm having is that the Oracle XML parser blows chunks and
won't properly parse documents in order for FOP to work correctly. I have
everything working properly as long as I put Xerces and Xml-apis in the
pre-boot class path (e.g. "-Xbootclasspath^/p:...") and specifying Xalan as
the TransformFactory (e.g. "...
-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.Transfor
merFactoryImpl).

However, although this configuration works perfectly, Oracle has
specifically declared that it will not be supported. Basically if
Xerces/Xalan ever blows up Oracle Reports, our enterprise's million dollar
support contract is worthless.

S...  Question: Is there any other way to force FOP to use the
Xalan transformer factory without overriding it for the entire Oracle
Reports application? I may even be allowed the time and resources to create
a FOP patch in order to make this modification if required.

As always, thank you in advance for your thoughts.

Jeff

Re: Communication

[Jay Bryant]

Jay Bryant schrieb:

I tried to ask a question and got a returned mail notice (reason: 552
Message rejected as it is spam (body))

So how do I attach code and ask a question about it?


Maybe send it inline instead as a attachement?
I guess the simplest thing would be to publish it on website somewhere
and just send the link (I don't know if your ASF account is already set
up but as a committer you have a "personal webspace" [1])

Christian

[1] http://www.apache.org/dev/new-committers-guide.html#public_html



Hi, Christian (and other folks),

As it happens, I figured out my problem (my Ant target was putting the 
META-INF folder in the wrong place). However, it's good to know that we have 
some web space, so that we can share implementation ideas before commiting 
them.


Thanks.

Jay Bryant
Bryant Communication Services 

Re: Render a PNG into RTF after having rendered into a PDF works only using imageFactory.clearCaches()

[Andreas L Delmelle]

On Feb 1, 2007, at 21:53, Koen Heene wrote:



I have the feeling that the image cache doesn't properly reuse the
image (maybe because of the multi threaded environment), holds a lock
on the PNG file and therefore doesn't allow that file to be re-read.


Looking into the code, it seems like clearCaches() should be removed  
(it is used nowhere; if it is not meant to be called, then it should  
be suppressed).


In the normal course of events, images are released via a call to  
ImageCache.releaseImage(). clearCaches() works differently, leading  
to this strange NPE...


What Exception do you get when a PDF is rendered first? There's a  
patch in queue (bugzilla 41488) which may solve your problem.



HTH!

Cheers,

Andreas

Render a PNG into RTF after having rendered into a PDF works only using imageFactory.clearCaches()

[Koen Heene]

Hello

I have a web application (thus multi threaded) where people can
request a xml document in PDF or RTF. The document contains a PNG
image.

A web request for rendering into a PDF is always successful. A web
request for rendering into a RTF is (most of the time) not successful,
when a PDF was already requested for that same document. Rendering
into a RTF is successful when no PDF was requested yet.

I solved the problem calling imageFactory.clearCaches(), which you
strongly advise not to call in the documentation. I force the
re-reading of the PNG-file in that way, isn't it?

I read a bit in the mailing lists and found similar messages, but the
Java Exception I get is

1/Fev/2007 20:50:34 org.apache.fop.render.rtf.RTFHandler image
SEVERE: Error while handling an external-graphic: null
java.lang.NullPointerException
   at org.apache.fop.image.PNGImage.loadOriginalData(PNGImage.java:74)
   at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:174)
   at org.apache.fop.render.rtf.RTFHandler.image(RTFHandler.java:1131)

which is different form the exceptions I have seen in the mailing lists.

I have the feeling that the image cache doesn't properly reuse the
image (maybe because of the multi threaded environment), holds a lock
on the PNG file and therefore doesn't allow that file to be re-read.

Any ideas or solutions?

Koen


[EMAIL PROTECTED]

PORTUGAL
Tel.: +351.282.973330
Mobile: +351.960025701

BELGIE
Mobile: +32.486.329106

Render a PNG into RTF after having rendered into a PDF works only using imageFactory.clearCaches()

[Koen Heene]

Hello

I have a web application (thus multi threaded) where people can
request a xml document in PDF or RTF. The document contains a PNG
image.

A web request for rendering into a PDF is always successful. A web
request for rendering into a RTF is (most of the time) not successful,
when a PDF was already requested for that same document. Rendering
into a RTF is successful when no PDF was requested yet.

I solved the problem calling imageFactory.clearCaches(), which you
strongly advise not to call in the documentation. I force the
re-reading of the PNG-file in that way, isn't it?

I read a bit in the mailing lists and found similar messages, but the
Java Exception I get is

1/Fev/2007 20:50:34 org.apache.fop.render.rtf.RTFHandler image
SEVERE: Error while handling an external-graphic: null
java.lang.NullPointerException
   at org.apache.fop.image.PNGImage.loadOriginalData(PNGImage.java:74)
   at org.apache.fop.image.AbstractFopImage.load(AbstractFopImage.java:174)
   at org.apache.fop.render.rtf.RTFHandler.image(RTFHandler.java:1131)

which is different form the exceptions I have seen in the mailing lists.

I have the feeling that the image cache doesn't properly reuse the
image (maybe because of the multi threaded environment), holds a lock
on the PNG file and therefore doesn't allow that file to be re-read.

Any ideas or solutions?

Koen

DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41514





--- Additional Comments From [EMAIL PROTECTED]  2007-02-01 12:13 ---
The patch is fairly large and seems to address more than only validation of the
configuration file. Can you give a summary?

I am against this exception being thrown if I do not use the font arial at all:

[ERROR] FOP - Exception
org.apache.avalon.framework.configuration.ConfigurationException:
Failed to resolve font metric-url 'arial.xml'

I am also against combining strict validation of the FO file and the user
configuration; they are two different things. I would appreciate a separate
option 'validate-configuration', which checks every entry in the configuration 
file.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 40288] - url requires "/", failes otherwise

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40288


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-02-01 07:38 ---
This bug should be fixed/addressed by [PATCH]
http://issues.apache.org/bugzilla/show_bug.cgi?id=41514

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 40120] - font-base wrongly interpreted when embedding font and input in folder

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40120


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-02-01 07:36 ---
This bug should be fixed/addressed by [PATCH]
http://issues.apache.org/bugzilla/show_bug.cgi?id=41514

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41514





--- Additional Comments From [EMAIL PROTECTED]  2007-02-01 07:34 ---
Created an attachment (id=19493)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19493&action=view)
new package (and files) under test/src/org.apache.fop.config


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41514] - [PATCH] Strict url validation of user config

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41514





--- Additional Comments From [EMAIL PROTECTED]  2007-02-01 07:32 ---
Created an attachment (id=19492)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19492&action=view)
main patch file


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 41514] New: - [PATCH] Strict url validation of user config

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41514

   Summary: [PATCH] Strict url validation of user config
   Product: Fop
   Version: 0.93
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: general
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Configuration checking for fonts and base urls is now much stricter
given true (this is the default value)
in the user config

This should address the following bugs :-

http://issues.apache.org/bugzilla/show_bug.cgi?id=40120
http://issues.apache.org/bugzilla/show_bug.cgi?id=40288

Patch file and zip file containing new files will be attached.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Feature and Bug

[Chris Bowditch]

Jim Tivy wrote:


Hi Folks

I am new to this community.  Thanks to all the FOP contributors to getting
this out.

We are trying to deploy a formatting solution to a customer.  One reason we
chose .93 was because it would allow us to define an even page with zero
renderable space - done by setting a top and bottom margin adding up to 11
inches:


Another possibility is to name the fo:region-body on even page masters 
with a different region name. That way they should be excluded from the 
flowing content which is tied to the region body on odd pages only.





 
 
  

This works great, except every once in a while FOP .93 decides it is
experiencing a flow problem and decides to render on this "zero space page".
FOP seems quite erratic when it decides to do this illegal rendering - seems
to be related to how the blocks are nested and what follows the text.  As
well, FOP knows it is doing something wrong and issues a warning:

Jan 31, 2007 2:10:12 PM org.apache.fop.layoutmgr.PageSequenceLayoutManager$1
notifyOverflow
WARNING: Content of the region-body on page 6 overflows the available area
in block-progression dimension. (fo
:page-sequence, location: 217/74)


Interesting. I'll let one of the layout experts comment on this. 
Certainly not what I'd expect.




Is there anyone who can help me with this bug and/or should it be reported
elsewhere.


BTW, you have posted to an inappropriate mailing list. The correct list 
for user questions on FOP is [EMAIL PROTECTED] The 
developers check the user list just as often as this list!




As well, I can make the .fo files available as necessary.


Thanks,

Chris

Re: Communication

[Christian Geisert]

Jay Bryant schrieb:
> I tried to ask a question and got a returned mail notice (reason: 552
> Message rejected as it is spam (body))
> 
> So how do I attach code and ask a question about it?

Maybe send it inline instead as a attachement?
I guess the simplest thing would be to publish it on website somewhere
and just send the link (I don't know if your ASF account is already set
up but as a committer you have a "personal webspace" [1])

Christian

[1] http://www.apache.org/dev/new-committers-guide.html#public_html