cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-2158) XMLByteStreamCompiler hard-coded limits of 0xffff Strings prevents large XML documents from being handled in Cocoon
Date Fri, 04 Jan 2008 14:04:33 GMT

    [ https://issues.apache.org/jira/browse/COCOON-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555932#action_12555932
] 

Vadim Gritsenko commented on COCOON-2158:
-----------------------------------------

I'd like to point out that attached patch introduces new limit (which is more likely to occur):
text size is now limited to 65k bytes (32k characters or less of UTF-8).

Another two issues with the patch are:
* It does not take into account that this code was refactored in trunk
* It does not recognize CXML10, introduces CXML11 as replacement.

IMHO It would be easier - and will be compatible - to extend handling of the large index instead
of applying patch as is.

> 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.


Mime
View raw message