|
*** This bug has been marked as a duplicate of 25710 *** I don't know what triggered Christine Li to believe that this bug is a
duplicate of 25710. That bug is something totally different IMO. Anyway I'm reopening this bug as it still persists in the current CVS HEAD and it renders Barcode4J's (formerly Krysalis Barcode) Xalan extension virtually useless in conjunction with Apache FOP if output from Xalan is piped into FOP using SAX. I've also finally managed to find the time to fix the bug. Since I haven't managed, yet, to run all the test suites I can't tell if the patch breaks anything. At least it passes the test case I've attached when submitting this bug. I will give the test suites another try tomorrow when I'm fully awake again. Created an attachment (id=12533)
Proposed patch to fix the bug I've been able to run the tests. With and without my patch Xalan-J's smoketest
shows one failure. Unfortunately, "build alltest" simply had too many failures to be helpful. Maybe I did something wrong running these tests.
Serge Knystautas made changes - 02/Sep/04 09:54 PM
Henry Zongaro made changes - 16/Dec/04 04:06 PM
Is there anything I can do to finally get this patch applied? It is a simple patch including a test case. This fixes a very annoying problem. Thanks!
Brian Minchau made changes - 21/Oct/05 04:46 AM
Jeremias,
your "Ping!" caught my attention. For some reason I have an interest in SAX events, and that the events are, shall we say, well-formed. Thanks for the full testcase, and patch. Sorry one of the Xalan committers didn't have a look earlier. Assuming the patch is OK, and applied to CVS HEAD, is that sufficient, or are you wanting it in an official release, e.g. 2.7.1 ? One other point, since the patch was migrated from bugzilla, it is not marked as giving the rights to Apache. It seems silly, but please attach that patch yet again, with the appropriate checkbox set. Thanks Brian! I've attached a new patch created against latest CVS today. And I've reattached the test case. Since the test case is a set of three new files, one could argue that ALv2 §5 doesn't apply, but my CLA is on file. :-)
I'm happy if the patch makes it into CVS. I don't expect a bugfix release just because of the patch. But obviously, it will be helpful to point Barcode4J users to a Xalan release that has the bug fixed. So, if the fix makes it into the next normally scheduled release, I'm happy.
Jeremias Maerki made changes - 21/Oct/05 06:29 AM
I reviewed the patch and approve it. I have applied it to CVS head branch.
The fix only impacts DOM2DTM, and only its dispatchToEvents() method with is called by SerializerUtils.outputResultTreeFragment(), which is used in ElemCopyOf. So all in all it looks like the startDocument() endDocument() is not correct for outputting a fragment. It also passes the smoke test and conformance tests.
Brian Minchau made changes - 22/Oct/05 11:48 AM
Thanks, Brian. A question though: What's the reason you didn't commit the test case, too? Anything wrong with it?
The fixed version is marked as 2.7.1.
The affecteced version was marked as 2.7.1, which is clearly wrong. Changing the affected version to 2.7, which is better, though perhaps not fully accurate.
Brian Minchau made changes - 11/Dec/07 04:33 PM
Would the originator of this issue please verify that this issue is fixed in the 2.7.1 release, by adding a comment to this issue, so that we can close this issue.
A lack of response by February 1, 2008 will be taken as consent that we can close this resolved issue. Regards, Brian Minchau Works fine with 2.7.1. Issue can be closed. Thanks, Brian.
Closing this issue.
Jeremias: I'm impressed, 4 years later and you are still watching this issue!
Brian Minchau made changes - 12/Dec/07 07:14 AM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
[PATCH] DocumentFragment returned by extension element causes multiple SAX endDocument() events
Testcase