Bug 5010 - Better error reporting needed
Summary: Better error reporting needed
Status: CLOSED WONTFIX
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: all
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
: 6539 12398 19914 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-11-21 12:28 UTC by Carlos Araya
Modified: 2012-04-30 00:17 UTC (History)
4 users (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Araya 2001-11-21 12:28:43 UTC 
The following error

[elrond@rivendell archive]$ /usr/local/java/fop1/fop.sh \
-xml admin-faq.xml -xsl \
 xsl/fo/docbook.xsl \
-pdf admin-faq.pdf

[INFO]: FOP 1.0dev
[ERROR]: null

is completely meaningless and doesn't help me detect if the problem is 
with the stylesheet, the document or Fop. Is there anyway to setup a 
verbose flag or a better and more meaningful error message than just 
null? I've tried this with both 0.20.2 and 1.0Dev
Comment 1 Corinna 2001-11-26 02:16:11 UTC 
I agree with you, error reporting must become better. 

In most of the cases, "Error: null" appears, if there is a problem in xsl 
transformation. To work around this, let xalan first generate a .fo file:

java -cp <your-classpath> org.apache.xalan.xslt.Process \
  -in admin-faq.xml -xsl xsl/fo/docbook.xsl -out admin-faq.fo

If there is a problem in your xsl, xalan will tell you.
Comment 2 J.Pietschmann 2002-05-15 14:22:09 UTC 
FOP-1.0dev is a development version, not a release. Don't use it, usually
it doesn't work.
Comment 3 J.Pietschmann 2002-09-08 15:33:04 UTC 
*** Bug 12398 has been marked as a duplicate of this bug. ***
Comment 4 Oleg Tkachenko 2002-11-14 17:55:54 UTC 
*** Bug 6539 has been marked as a duplicate of this bug. ***
Comment 5 J.Pietschmann 2003-05-14 14:58:56 UTC 
*** Bug 19914 has been marked as a duplicate of this bug. ***
Comment 6 Glenn Adams 2012-04-04 20:30:56 UTC 
no FO input file provided; insufficiently specific problem description
Comment 7 Jesse Glick 2012-04-04 20:59:39 UTC 
Duplicate bug #6539 did provide a complete test case. Still reproducible in FOP 0.20.3 a decade later using JDK 7 (!):

java.lang.NullPointerException
	at org.apache.fop.fo.PropertyManager.getTextDecoration(PropertyManager.java:260)
	at org.apache.fop.fo.flow.Block.<init>(Block.java:75)
	at org.apache.fop.fo.flow.Block$Maker.make(Block.java:37)
	at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:261)

When updated to use FOP 1.0, a more reasonable error is produced:

org.apache.fop.fo.ValidationException: "{http://www.w3.org/1999/XSL/Format}block" is not a valid child of "fo:root"! (See position 1:5275)
	at org.apache.fop.events.ValidationExceptionFactory.createException(ValidationExceptionFactory.java:38)
	at org.apache.fop.events.EventExceptionManager.throwException(EventExceptionManager.java:54)
	at org.apache.fop.events.DefaultEventBroadcaster$1.invoke(DefaultEventBroadcaster.java:175)
	at $Proxy0.invalidChild(Unknown Source)
	at org.apache.fop.fo.FONode.invalidChildError(FONode.java:534)
	at org.apache.fop.fo.FONode.invalidChildError(FONode.java:517)
	at org.apache.fop.fo.pagination.Root.validateChildNode(Root.java:133)
	at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:267)
	at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171)

So this was fixed somewhere along the line and the fixer just did not know about this bug report.
Comment 8 Glenn Adams 2012-04-04 21:26:15 UTC 
(In reply to comment #7)
> Duplicate bug #6539 did provide a complete test case. Still reproducible in FOP
> 0.20.3 a decade later using JDK 7 (!):

> So this was fixed somewhere along the line and the fixer just did not know
> about this bug report.

thanks for additional info!
Comment 9 Glenn Adams 2012-04-30 00:15:02 UTC 
batch transition resolved+wontfix to closed+wontfix
Comment 10 Glenn Adams 2012-04-30 00:17:26 UTC 
batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen