You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2006/05/11 16:23:58 UTC
DO NOT REPLY [Bug 39560] New: - Null Pointer Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
Summary: Null Pointer Exception
Product: Fop
Version: 0.92
Platform: PC
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: pdf
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: joachim.unger@softwareag.com
I got a NPE rendering PDF documents. There are no other messages! Any idea?
Regards,
Joachim
6359 [WT4] WARN Converter - Converter.run: Retrying FO --> PDF in thread 4
java.lang.NullPointerException
at org.apache.fop.fo.flow.TableRow.addChildNode(TableRow.java:193)
at org.apache.fop.fo.FONode.clone(FONode.java:83)
at org.apache.fop.fo.FObj.clone(FObj.java:96)
at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:143)
at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:145)
at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:145)
at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:145)
at org.apache.fop.fo.flow.RetrieveMarker.cloneFromMarker(RetrieveMarker.java:163)
at org.apache.fop.fo.flow.RetrieveMarker.bindMarker(RetrieveMarker.java:214)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMarker(PageSequenceLayoutManager.java:653)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.createChildLMs(AbstractLayoutManager.java:247)
at
org.apache.fop.layoutmgr.BlockLayoutManager$ProxyLMiter.createNextChildLMs(BlockLayoutManager.java:146)
at
org.apache.fop.layoutmgr.BlockLayoutManager$ProxyLMiter.hasNext(BlockLayoutManager.java:139)
at
org.apache.fop.layoutmgr.BlockLayoutManager.createNextChildLMs(BlockLayoutManager.java:159)
at org.apache.fop.layoutmgr.LMiter.hasNext(LMiter.java:39)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:107)
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:258)
at
org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
at
org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:160)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.createElementsForRowGroup(TableContentLayoutManager.java:467)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:237)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:176)
at
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:233)
at
org.apache.fop.layoutmgr.StaticContentLayoutManager$StaticContentBreaker.getNextKnuthElements(StaticContentLayoutManager.java:306)
at
org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:502)
at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:252)
at
org.apache.fop.layoutmgr.StaticContentLayoutManager.doLayout(StaticContentLayoutManager.java:230)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.layoutSideRegion(PageSequenceLayoutManager.java:688)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:695)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.makeNewPage(PageSequenceLayoutManager.java:660)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.handleBreakTrait(PageSequenceLayoutManager.java:729)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.access$100(PageSequenceLayoutManager.java:57)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.startPart(PageSequenceLayoutManager.java:467)
at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.java:370)
at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.java:321)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.doPhase3(PageSequenceLayoutManager.java:331)
at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:296)
at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:220)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:152)
at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:320)
at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:147)
at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:357)
at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:193)
at
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1050)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:452)
at Converter.run(Converter.java:284)
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From jeremias@apache.org 2006-05-18 16:45 -------
Test case added: http://svn.apache.org/viewvc?rev=407588&view=rev
Any table put in a marker fails when it's referenced through a retrieve-marker.
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From a_l.delmelle@pandora.be 2006-06-03 00:33 -------
I think I see what the problem is here... expect a fix soon.
See TableBody.endOfNode(). usedColumnIndices is set to null, as I mistakenly supposed this wouldn't be
used again... Overlooked the case of the table being cloned due to marker-retrieval :(
--
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 39560] - Null Pointer Exception
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From jeremias@apache.org 2006-05-12 07:46 -------
Looking at the stack trace it must be something with the combination of
retrieve-marker and tables. The exception handles because usedColumnIndices is
null. usedColumnIndices is instantiated a few lines above but only if certain
conditions are met. There's also another line in TableRow.startOfNode() which
gets the usedColumnIndices from the parent table-body. Try debugging in that area.
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From a_l.delmelle@pandora.be 2006-06-03 01:17 -------
OK, yet another one of my gut feelings at the time has hereby been proven correct: putting that stuff in
addChildNode() wasn't such a good idea... Sorry :/
Now as for the solution: I'm thinking along the lines of moving the related code from i.e.
TableRow.addChildNode() to TableCell.endOfNode(), since the latter is guaranteed to occur only once per
actual table-cell --regardless of whether it gets cloned afterwards due to marker-retrieval. The same info
will be available, only through the parent instead of directly.
Shouldn't prove to be too difficult, but before I begin:
Does anyone disagree with the change described above?
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From a_l.delmelle@pandora.be 2006-06-03 00:50 -------
Looking at what happens a bit more closely: I was on the right track --in thinking that it was unnecessary
to keep the BitSet alive after the TableBody/TableRow node ended.
The whole column-numbering process should not be repeated at any rate, since it was already completed
when that fragment was parsed, so the TableColumn/TableCell instances will, at that point already contain
the correct initial values.
Back to the investigation :)
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From a_l.delmelle@pandora.be 2006-06-06 22:30 -------
NPE is fixed, but I wouldn't use tables in markers just yet... there are still remaining problems.
--
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 39560] - Null Pointer Exception
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From joachim.unger@softwareag.com 2006-05-11 17:04 -------
I tried to reduce some information in the fo-file because the data is
confidential. But then the error disappears. Sorry. I will need some time to
find an example.
Might it be a memory problem or a problem with tables (many rows, marker in
every tow) over more than one page?
All my other documents were rendered perfectly.
Regards,
Joachim
--
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 39560] - Null Pointer Exception
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
bowditch_chris@hotmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
------- Additional Comments From bowditch_chris@hotmail.com 2006-05-11 15:37 -------
Please attached a small FO file that demonstrates the problem
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
jeremias@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
Summary|Null Pointer Exception |Null Pointer Exception (when
| |a table cloned due to a
| |retrieve-marker operation)
------- Additional Comments From jeremias@apache.org 2006-05-18 16:25 -------
Ok, it looks like it's really the column handling code in TableRow that's
falling appart as soon as a table is cloned due to a retrieve-marker operation
from a marker which contains a table. I don't see a solution, yet. I'll build a
small test case we can put in the test suite. If anyone has ideas how to fix
this....
--
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 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From a_l.delmelle@pandora.be 2006-06-05 23:05 -------
OK. Good news first: I managed to fix the NPE as described, by moving the code related to updating the
table FOs column indices to TableCell.startOfNode() / TableCell.endOfNode(). Still have to do the same for
the columns...
Bad news: still have to investigate why our testcase now ends up being... completely empty ?
Nothing but <areaTree />...
--
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 39560] - Null Pointer Exception
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
------- Additional Comments From joachim.unger@softwareag.com 2006-05-16 07:07 -------
Created an attachment (id=18294)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=18294&action=view)
FO-Input not converted by FOP 0.92
--
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.
Summary Marker Property/Percentage Resolution (was: Re: DO NOT REPLY [Bug 39560] ... )
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 15, 2006, at 18:42, Andreas L Delmelle wrote:
<snip />
Ok, final summary of what I'm going to attempt:
-> introduce an inMarker boolean switch in the FOTree
still a few doubts on where to store this, but the Flow seemed like
a good candidate (markers have to be flow-descendants)
OTOH, FOEventHandler also seems OK, and has the advantage of being
readily accessible from everywhere through FObj.getFOEventHandler()
(and thus, FOEventHandler subclasses, like the RTFHandler, would
also
be able to make use of it?)
other use-case of this switch: turn off white-space handling, and
defer it to the marker-retrieval context (integrate into the cloning
process)
-> alter FOTreeBuilder$MainFOHandler.startElement()
if node is a Marker, switch context (inMarker = true)
when inMarker is true:
no call to FONode.createPropertyList(), and pass null as property
list into FONode.processNode()
when inMarker is false:
same as before
-> alter FOTreeBuilder$MainFOHandler.endElement()
if node is a Marker, switch context (inMarker = false)
-> alter FObj.processNode()
when inMarker is true:
no binding of the FO to the property list (which will be null
anyway),
merely keep a reference to the original Attributes (somehow I'd
expect
these to be smaller than a corresponding PropertyList, but in
the end,
this depends on the XML parser implementation? Slightly more
than a Map?)
when inMarker is false and pList is null
avoid NPE (shouldn't happen, but you never know)
when inMarker is false and pList not null
same as before
-> in RetrieveMarker, right after the marker-children are cloned, call
clone.createPropertyList(), feeding it the storedPropertyList and
the Attribute.
Then call clone.processNode(). Maybe RetrieveMarker also needs a
currentProperyList, like FOTreeBuilder, in order to pass the
proplist
down in to the subtree when cloning.
This should fix the percentage resolution, as well as the bug
concerning evaluation of relative font-sizes (ems) in Markers. All
property parsing/resolution for marker descendants will be deferred,
and performed only when the marker is actually retrieved.
FTM, nothing will be changed where it comes to the cloning process.
Simon's idea of reusing the original FObjs is definitely interesting,
but it would also mean that they need to be reparented to the Marker
after the LMs are created, and their properties (instance variables)
would need to be reset. Problems may arise if this is done, and
afterwards the LM accesses the instance variables of its FObj... I'm
not sure whether it's doable. :/
The RetrieveMarkerPropertyList question is less urgent (merely
streamlining, no bugfixing).
Back to work! :)
Later,
Andreas
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 14, 2006, at 19:16, Simon Pepping wrote:
Hi Simon,
> On Mon, Jun 12, 2006 at 07:36:34PM +0200, Andreas L Delmelle wrote:
>> On Jun 12, 2006, at 15:29, Simon Pepping wrote:
>>
>>> There may be problems with the property lists of the Marker
>>> children,
>>> which are currently not cloned, but referred to in descPlists. The
>>> property lists of a subtree of a marker are special, because they
>>> must
>>> be kept alive for later retrieval. Other property lists are garbage
>>> collected after the properties have been bound to the LM and the
>>> subtree of the FO has been processed.
>>
>> Not all, unfortunately. See the comment in RetrieveMarker about using
>> StaticPropertyList (which stores a reference to its
>> parentPropertyList, which also happens to be a StaticPropertyList
>> etc. until the PropertyList for the fo:root) :/
>
> Fortunately. That is the other side of the coin. The property lists in
> the ancestry of a retrieve-marker also need to be protected from
> garbage collection, in order to be able to resolve properties after
> retrieval of a marker.
Well, maybe I was thinking too much in terms of memory that is
occupied too long. StaticPropertyList is, as its javadoc explains, an
ultra-fast array based implementation that eats substantially more
memory than an instance of its superclass... hence the idea of
MarkerPropertyList, I'd say.
In case of retrieve-markers, the consequences are less drastic,
because they generally appear not too deeply nested, but still... The
cases where a property list holds values for more than 20-30 percent
of all possible properties are extremely rare (which means that for
the other 70-80%, bytes are allocated for the reference but never
occupied (=always null) --which makes it even more of a waste). I'm
not 100% sure, but I would say that this was Finn's key motivation
behind binding the properties to instance variables of the FObjs.
We could resolve inheritance up to the retrieve-marker at parse-time,
and build a special PropertyList which 'merges/flattens/collapses' --
can't seem to find the right word-- the lists of the ancestors.
We'd only need to make sure to override methods like getInherited()
to not go looking for a parentPropertyList, but simply return the
value from that special PropertyList attached to the RetrieveMarker.
Inheritance for properties specified on the marker-descendants
obviously has to wait until the layout-phase.
Then again, maybe I'm seeing things too simplistic and those (4 bytes
per reference * some 250 properties * the number of
StaticPropertyLists) don't mean all that much...?
Cheers,
Andreas
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table
cloned due to a retrieve-marker operation)
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Mon, Jun 12, 2006 at 07:36:34PM +0200, Andreas L Delmelle wrote:
> On Jun 12, 2006, at 15:29, Simon Pepping wrote:
>
> >There may be problems with the property lists of the Marker children,
> >which are currently not cloned, but referred to in descPlists. The
> >property lists of a subtree of a marker are special, because they must
> >be kept alive for later retrieval. Other property lists are garbage
> >collected after the properties have been bound to the LM and the
> >subtree of the FO has been processed.
>
> Not all, unfortunately. See the comment in RetrieveMarker about using
> StaticPropertyList (which stores a reference to its
> parentPropertyList, which also happens to be a StaticPropertyList
> etc. until the PropertyList for the fo:root) :/
Fortunately. That is the other side of the coin. The property lists in
the ancestry of a retrieve-marker also need to be protected from
garbage collection, in order to be able to resolve properties after
retrieval of a marker.
Simon
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 12, 2006, at 15:29, Simon Pepping wrote:
Hi Simon,
> <snip />
> I wrote some of this code over 1 1/2 years ago. Apparently I had the
> wrong impression that the marker subtree could be attached to the
> retrieve marker.
>
> Would it not be the best solution in this stack:
>
> at org.apache.fop.fo.flow.RetrieveMarker.cloneFromMarker
> (RetrieveMarker.java:163)
> at org.apache.fop.fo.flow.RetrieveMarker.bindMarker
> (RetrieveMarker.java:214)
> at
> org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMark
> er(PageSequenceLayoutManager.java:653)
> at
> org.apache.fop.layoutmgr.AbstractLayoutManager.createChildLMs
> (AbstractLayoutManager.java:247)
>
> to let RetrieveMarker.cloneFromMarker return the Marker's children,
> the same for RetrieveMarker.bindMarker and
> PageSequenceLayoutManager.resolveRetrieveMarker, so that
> AbstractLayoutManager.createChildLMs can add them as if they were its
> own children?
That's a very interesting approach, and may save us some... It could
work, provided that, after those nodes are returned, there is either
no call to the marker-child's getParent(), or the marker-child's
"parent" member is modified (temporarily, as the marker may be
retrieved again further on, into a different context).
PropertyParser.parse() returns a Property instance, which may be a
LengthBase or subtype. If that is the case, then the LengthBase is
instantiated with the original FO as a parameter to its constructor.
No matter what we do with the FO --cloning-- or the PropertyList --
unparent/reparent-- afterwards, those LengthBases will refer to
another FO instance. If we can make sure somehow that that same FO
will be the one for which the LM is created, then the problem would
also vanish.
> There may be problems with the property lists of the Marker children,
> which are currently not cloned, but referred to in descPlists. The
> property lists of a subtree of a marker are special, because they must
> be kept alive for later retrieval. Other property lists are garbage
> collected after the properties have been bound to the LM and the
> subtree of the FO has been processed.
Not all, unfortunately. See the comment in RetrieveMarker about using
StaticPropertyList (which stores a reference to its
parentPropertyList, which also happens to be a StaticPropertyList
etc. until the PropertyList for the fo:root) :/
The preferrable strategy there, I think, is to 'flatten' the tree of
PropertyLists, such that a special RetrieveMarkerPropertyList would
contain:
a) the explicit properties specified on the RM's parent
b) the inherited properties (preferrably only those with values other
than the default)
c) no reference to a parentPropertyList
Same thing BTW for the PropertyLists of fo:table-columns, which we
need to keep a reference to for resolving calls to from-table-column().
And to add to all the fun: imagine a fo:block in a marker, with from-
table-column() in one of its properties --if the marker is not the
descendant of a table-cell, IIC, this would currently throw a
ValidationException. But maybe this validation should be performed
upon retrieving the marker. If the fo:retrieve-marker is descendant
of an fo:table-cell, then from-table-column() would be valid, at
least I think so... Can't find any literal references in the Rec.
Well, it's exotic, but not unthinkable.
Later,
Andreas
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table
cloned due to a retrieve-marker operation)
Posted by Simon Pepping <sp...@leverkruid.eu>.
On Thu, Jun 08, 2006 at 02:30:09PM +0200, Andreas L Delmelle wrote:
> On Jun 7, 2006, at 20:46, Andreas L Delmelle wrote:
>
> ><snip />
> >And so I did... Guess what: there seems to be an inherent error in
> >the marker descendant re-parenting process. It must have been there
> >for quite a while. Nobody ever noticed. :)
> >Some debugging showed that the clones of the marker descendants
> >have a RetrieveMarker as a parent (instead of the parent of the
> >RetrieveMarker as prescribed by the Rec)
> >
> >So, good news: Should be easy to fix, and the percentage resolution
> >should work like a charm. :)
>
> Looking closer, this error does have its reasons it seems...
>
> RetrieveMarkers are resolved in the parent's createChildLMs(), in
> iterating over the list of childNodes. Subsequently, the
> RetrieveMarker is unable to reparent the cloned subtree to its own
> parent, since this would lead to a ConcurrentModificationException...
>
> It's probably going to be easier to get the percentage resolution to
> point to the RetrieveMarker's parent in case it encounters a
> RetrieveMarker.
I wrote some of this code over 1 1/2 years ago. Apparently I had the
wrong impression that the marker subtree could be attached to the
retrieve marker.
Would it not be the best solution in this stack:
at org.apache.fop.fo.flow.RetrieveMarker.cloneFromMarker(RetrieveMarker.java:163)
at org.apache.fop.fo.flow.RetrieveMarker.bindMarker(RetrieveMarker.java:214)
at
org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMarker(PageSequenceLayoutManager.java:653)
at
org.apache.fop.layoutmgr.AbstractLayoutManager.createChildLMs(AbstractLayoutManager.java:247)
to let RetrieveMarker.cloneFromMarker return the Marker's children,
the same for RetrieveMarker.bindMarker and
PageSequenceLayoutManager.resolveRetrieveMarker, so that
AbstractLayoutManager.createChildLMs can add them as if they were its
own children?
There may be problems with the property lists of the Marker children,
which are currently not cloned, but referred to in descPlists. The
property lists of a subtree of a marker are special, because they must
be kept alive for later retrieval. Other property lists are garbage
collected after the properties have been bound to the LM and the
subtree of the FO has been processed. Maybe it is best to just copy
the property lists of the marker subtree. The copies will be garbage
collected in the normal way.
I have no time to try this solution myself.
Simon
>
> Later,
>
> Andreas
>
--
Simon Pepping
home page: http://www.leverkruid.eu
Re: percentage resolution in markers (was: Re: DO NOT REPLY [Bug 39560] ...)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Sounds like the right approach, since the property inheritance needs to
be going up the hierarchy after the retrieve-marker has been resolved. I
hope it's not too difficult to implement. I haven't taken a closer look
myself.
On 11.06.2006 15:28:57 Andreas L Delmelle wrote:
> On Jun 11, 2006, at 03:56, Andreas L Delmelle wrote:
>
> Just FYI:
> > Some more follow-up on the problem WRT percentage resolution in
> > markers:
> >
> > <snip />
> > My suspicion that the percentage resolution is done purely via the
> > FOs pointed to by the PropertyList turned out to be correct, and
> > what I'm currently looking at is rather nasty... 8)
> >
> > The PropertyLists stored in the marker are created based on the
> > original FOs, which means, IIC that all LengthBases or instances of
> > derived classes in that PropertyList get a reference to the
> > original FO.
> > Later on, when RetrieveMarker is resolved, the marker descendants
> > are cloned and the clones are then bound to these PropertyLists
> > (=Map descPLists in Marker.java).
> > As a result, the percentage resolution tries to climb a tree of LMs
> > that was never created (there is no LM corresponding to the
> > original FO)
>
> I think the correct way to solve this, is to have the Markers store
> references, not to the PropertyLists, but to the original Attributes.
> pList.addAttributesToList() should be called only after the clone is
> created.
>
> IOW: simply defer that call for every passing node when
> 'IN_MARKER_CONTEXT' (=non-existing variable, member of Flow?), and
> instead store the Attributes of the Marker descendants in the
> HashMap. The PropertyList should also be instantiated only during the
> cloning process (the clone needs to be passed to its constructor to
> make everything work correctly).
>
> The intention of the MarkerPropertyList subtype seems correct, but it
> doesn't go far enough (should store the original Attributes instead
> of the parsed explicit properties; once they're parsed the damage is
> already done, so to speak).
>
>
> Later,
>
> Andreas
Jeremias Maerki
Re: percentage resolution in markers (was: Re: DO NOT REPLY [Bug 39560] ...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 11, 2006, at 03:56, Andreas L Delmelle wrote:
Just FYI:
> Some more follow-up on the problem WRT percentage resolution in
> markers:
>
> <snip />
> My suspicion that the percentage resolution is done purely via the
> FOs pointed to by the PropertyList turned out to be correct, and
> what I'm currently looking at is rather nasty... 8)
>
> The PropertyLists stored in the marker are created based on the
> original FOs, which means, IIC that all LengthBases or instances of
> derived classes in that PropertyList get a reference to the
> original FO.
> Later on, when RetrieveMarker is resolved, the marker descendants
> are cloned and the clones are then bound to these PropertyLists
> (=Map descPLists in Marker.java).
> As a result, the percentage resolution tries to climb a tree of LMs
> that was never created (there is no LM corresponding to the
> original FO)
I think the correct way to solve this, is to have the Markers store
references, not to the PropertyLists, but to the original Attributes.
pList.addAttributesToList() should be called only after the clone is
created.
IOW: simply defer that call for every passing node when
'IN_MARKER_CONTEXT' (=non-existing variable, member of Flow?), and
instead store the Attributes of the Marker descendants in the
HashMap. The PropertyList should also be instantiated only during the
cloning process (the clone needs to be passed to its constructor to
make everything work correctly).
The intention of the MarkerPropertyList subtype seems correct, but it
doesn't go far enough (should store the original Attributes instead
of the parsed explicit properties; once they're parsed the damage is
already done, so to speak).
Later,
Andreas
percentage resolution in markers (was: Re: DO NOT REPLY [Bug 39560] ...)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 8, 2006, at 14:30, Andreas L Delmelle wrote:
Some more follow-up on the problem WRT percentage resolution in markers:
> <snip />
> RetrieveMarkers are resolved in the parent's createChildLMs(), in
> iterating over the list of childNodes. Subsequently, the
> RetrieveMarker is unable to reparent the cloned subtree to its own
> parent, since this would lead to a ConcurrentModificationException...
>
> It's probably going to be easier to get the percentage resolution
> to point to the RetrieveMarker's parent in case it encounters a
> RetrieveMarker.
I'm not so sure anymore which one of the two options will be easier...
Debugging further showed me that getBaseLength() is being called with
the descendant of a Marker as parameter (the original one, not the
clone ?)
So I dug deeper, as this behaviour seemed rather peculiar to me. It
got even stranger as I put the breakpoints earlier. The
layoutmanagers are created as they should: with the cloned marker
descendants as their base FO. No problem so far. However, when you
look at the code in Marker, a special subtype of PropertyList is
created, and therein lies the problem, I think.
My suspicion that the percentage resolution is done purely via the
FOs pointed to by the PropertyList turned out to be correct, and what
I'm currently looking at is rather nasty... 8)
The PropertyLists stored in the marker are created based on the
original FOs, which means, IIC that all LengthBases or instances of
derived classes in that PropertyList get a reference to the original FO.
Later on, when RetrieveMarker is resolved, the marker descendants are
cloned and the clones are then bound to these PropertyLists (=Map
descPLists in Marker.java).
As a result, the percentage resolution tries to climb a tree of LMs
that was never created (there is no LM corresponding to the original FO)
Took a while to track down. Now all we need is a clean solution... :/
To Be Continued
Later,
Andreas
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 7, 2006, at 20:46, Andreas L Delmelle wrote:
> <snip />
> And so I did... Guess what: there seems to be an inherent error in
> the marker descendant re-parenting process. It must have been there
> for quite a while. Nobody ever noticed. :)
> Some debugging showed that the clones of the marker descendants
> have a RetrieveMarker as a parent (instead of the parent of the
> RetrieveMarker as prescribed by the Rec)
>
> So, good news: Should be easy to fix, and the percentage resolution
> should work like a charm. :)
Looking closer, this error does have its reasons it seems...
RetrieveMarkers are resolved in the parent's createChildLMs(), in
iterating over the list of childNodes. Subsequently, the
RetrieveMarker is unable to reparent the cloned subtree to its own
parent, since this would lead to a ConcurrentModificationException...
It's probably going to be easier to get the percentage resolution to
point to the RetrieveMarker's parent in case it encounters a
RetrieveMarker.
Later,
Andreas
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Jun 7, 2006, at 14:10, I wrote in Bugzilla:
<snip />
> More info on the remaining problem:
>
> It seems like the layoutengine currently tries to calculate widths
> for the descendants of the markers
> contained within it, which seems to lead to errors in
> AbstractBaseLM.getBaseLength()... ? Still have to
> investigate a bit further.
And so I did... Guess what: there seems to be an inherent error in
the marker descendant re-parenting process. It must have been there
for quite a while. Nobody ever noticed. :)
Some debugging showed that the clones of the marker descendants have
a RetrieveMarker as a parent (instead of the parent of the
RetrieveMarker as prescribed by the Rec)
So, good news: Should be easy to fix, and the percentage resolution
should work like a charm. :)
Later,
Andreas
DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39560>.
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=39560
a_l.delmelle@pandora.be changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From a_l.delmelle@pandora.be 2006-06-07 12:10 -------
OK, fixed in FOP Trunk.
More info on the remaining problem:
It seems like the layoutengine currently tries to calculate widths for the descendants of the markers
contained within it, which seems to lead to errors in AbstractBaseLM.getBaseLength()... ? Still have to
investigate a bit further. If anyone else feels like looking at this, be my guest ;)
If you use absolute widths on the tables instead of a percentage, everything works and displays nicely.
--
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.