Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 351704

Summary:	[StaxRecordReader] doesnt parse attributes with very long lines (large content) correctly when <?xml version="1.1"
Product:	z_Archived	Reporter:	thomas menzel <tmenzel>
Component:	Smila	Assignee:	Juergen Schumacher <juergen.schumacher>
Status:	CLOSED FIXED	QA Contact:
Severity:	critical
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description thomas menzel

2011-07-11 08:36:15 EDT

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()

Comment 1 Juergen Schumacher

2011-07-18 10:06:50 EDT

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?

Comment 2 thomas menzel

2011-07-18 10:13:03 EDT

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.

Comment 3 Juergen Schumacher

2011-07-18 11:14:12 EDT

No, I did not yet find a matching issue. But then, the search on bugs.sun.com sucks (-;

Comment 4 thomas menzel

2011-07-28 10:52:10 EDT

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

Comment 5 thomas menzel

2011-09-21 05:23:48 EDT

@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?

Comment 6 Juergen Schumacher

2011-09-21 05:35:01 EDT

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.

Comment 7 thomas menzel

2011-09-21 05:37:39 EDT

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.

Comment 8 thomas menzel

2011-09-23 05:54:46 EDT

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.