See the disabled testcase added here: http://svn.apache.org/viewvc?rev=672617&view=rev In current FOP Trunk, the test throws a NPE, due to AbstractRetrieveMarker not correctly cloning the foreign object. cloneSingleNode() apparently only deals with FObj and FOText, but XMLObj descends directly from FONode, so does not survive... Changing XMLObj to extend FObj, instead of FONode, partly fixes the issue. It clones the root of the document, but does not yet descend recursively.
I'm wondering whether we really need to clone the whole foreign subtree, as we are quite sure (?) that it's not FO and it's self-contained .... I'm attaching a patch that clones the foreign tree root without deleting the child pointers; I have performed a couple of tests and everything seems fine. (actually, now I think of it, the patch is slightly sub-optimal, as we could just clone the instream-foreign-object node and share the whole foreign subtree) If there are no remaining erroneous situations or objections I can apply the patch to the trunk.
Created attachment 22297 [details] "cheap" cloning of the foreign subtree
(In reply to comment #1) (Apologies for being so late with the reply) > I'm wondering whether we really need to clone the whole foreign subtree, as we > are quite sure (?) that it's not FO and it's self-contained .... Yep, now that you mention it. :-) Seems like it could also be solved by overriding InstreamForeignObject.clone(FONode, boolean), to always pass 'false' for the boolean parameter (= removeChildren)...? I'll look into it again later, and see what would work best. Thanks for the feedback.
I've recently fixed that locally without checking for an open Bugzilla entry. Now, I've stumbled over it. I guess I found yet another possible solution. I hope mine is acceptable, too. http://svn.apache.org/viewvc?rev=730764&view=rev
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed