Community
Participate
Working Groups
large content in a attribute isnt parsed correctly. the symptom i found is that in this case the attributes after the offending one become part of the content in their XML representation. i have created a test case for this but deactivated it. see TestXmlStaxUtilities._test_BugWhenParsing_LargeAttributes()
Seems to be a bug in the XMLStreamReader implementation provided by the JDK: The problem exists for JDKs up to version 7, but the test works if I add the Woodstox Stax implementation (http://woodstox.codehaus.org/) to the bundle classpath of the test bundle (checked version 3.2.9 and 4.1.1). However, to use this we would have to do a CQ (or use a very old version 3.2.4, for which we have an approved CQ (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2755), but which is not in the current codebase anymore. And we would have to figure out how to force all of SMILA to use it instead of the default JDK implementation. BTW, the default JDK parser works OK, if the extremely long line is splitted in two lines. So the problem it has it with "very long lines", not "large content", to be exact (-; How do we proceed?
not sure how to proceed... (need to think about this) but changing the summary of this bug to ur gained insight. is there a bug against JDK's XMLStreamReader? if so plz, ref' it here.
No, I did not yet find a matching issue. But then, the search on bugs.sun.com sucks (-;
i found another thing out today: if i take out the optional directive <?xml version="1.1" encoding="utf-8"?> then it works -- or at least i cannot reproduce the bug. it is also sufficient to set it to version 1.0.... i posted a bug for this @ bugs.sun.com and got the request ID 2087434 since we have a workaround know i set this to resolved
@JS since setting the version solves it, shouldnt we set the version 1.0 also when we serialize the record? and if yes: for brevity even completely drop the declaration, which then defaults silently to v1.0 and utf-8 anyhow?
Fine with me. However, I don't remember why it was set to 1.1 initially. It may have been to workaround of another problem.
i had looked up the diff between 1.1 and 1.0 already a while back, and it had smth. todo with line endings for some special encodings if i remember correctly. anyhow, since u are not sure on this i will post in in the dev list to get a broader view.
i have changed the version to 1.0. i did some digging thru the SVN version and i showed that JS had set this in rev 577 where he gave the class a complete overhaul. since he doesnt remember a good reason to have 1.1 i figured it is save to go back to 1.0.
