[
https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555969#action_12555969
]
Eric Meyer commented on COCOON-2158:
------------------------------------
Vadim - thank you for pointing out the 65k character limit - you saved me from
finding that the hard way. Definitely a problem. That nuance sure escaped me in
the original code... but that's why I gave up trying to rework the original
code - it was darn challenging to see what exactly was going on at the bit low
level. While it's not higher math, it wasn't obvious what it was doing or why.
Also thanks for pointing out the work on the 2.2. branch. You applied many of
the same refactorings that I did.
Since the format is not binary backward compatible, I changed the prolog to
CXML11. I couldn't find that defined as a standard anywhere.
I'm attaching a new patch that removes the 65k limit by instead writing the
integer length of the string followed by the characters. I also updated the
test to show that it can successfully handle more than 65k of \uffff characters.
Kind regards,
Eric
> XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML
> documents from being handled in Cocoon
> -------------------------------------------------------------------------------------------------------------------
>
> Key: COCOON-2158
> URL: https://issues.apache.org/jira/browse/COCOON-2158
> Project: Cocoon
> Issue Type: Bug
> Components: * Cocoon Core
> Affects Versions: 2.1.6, 2.1.7, 2.1.8, 2.1.9, 2.1.10, 2.1.11, 2.1.12-dev
> (Current SVN)
> Reporter: Eric Meyer
> Assignee: Antonio Gallardo
> Priority: Critical
> Attachments: cocoon-xmlbytestream.patch
>
>
> The hard-coded limits in XMLByteStreamCompiler prevent Cocoon from handling
> large XML documents.
> See the methods writeString and writeAttributes for the hard coded arbitrary
> maximums:
> if (i > 0xFFFF) throw new SAXException("Index too large");
> if (attributes > 0xFFFF) throw new SAXException("Too many attributes");
> Additionally, the hand-coded bit manipulation is pretty difficult to change
> in order to work around this.
> I am attaching a patch for 2.1.11 that updates the existing JUnit test case
> to reproduce the problem, as well as a fix to the problem that uses the
> DataInputStream and DataOutputStream for the low-level bit manipulation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
