DO NOT REPLY [Bug 39560] Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
https://issues.apache.org/bugzilla/show_bug.cgi?id=39560 Glenn Adams gl...@skynav.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #13 from Glenn Adams gl...@skynav.com 2012-04-01 06:49:02 UTC --- batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
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: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
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)
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
DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 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.
Re: DO NOT REPLY [Bug 39560] - Null Pointer Exception (when a table cloned due to a retrieve-marker operation)
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)
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 [EMAIL PROTECTED] 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 (when a table cloned due to a retrieve-marker operation)
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 [EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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)
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 [EMAIL PROTECTED] 2006-05-18 16:45 --- Test case added: http://svn.apache.org/viewvc?rev=407588view=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.
