[
https://issues.apache.org/jira/browse/OOZIE-2777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838760#comment-15838760
]
Harsh J commented on OOZIE-2777:
--------------------------------
Overall the change looks good.
Just some observances:
- The {{value == null}} guard inside {{writeString()}} would still throw up an
NPE, but that's just retaining the existing behaviour so it seems OK to me.
- I know it just preserves the existing implementation, but in the below
unchecked part of {{readString()}} do we perhaps need an upper limit integer
check? For a corrupted reads, the integer being negative or very close to max
would cause an OOME to be thrown during the array allocation (with either an
illegal size, or higher than limit exception). Not very likely/necessary, but
would generally be a good thing to have, thoughts?
{code}
int length = dIn.readInt();
byte[] data = new byte[length];
{code}
- Are the imports in {{TestLiteWorkflowAppParser.java}} necessary? They don't
seem to carry any other change.
- The test looks good. Could some comments be added on how the older format
serialised file was produced here just for posterity?
> Config-default.xml longer than 64k results in java.io.UTFDataFormatException
> -----------------------------------------------------------------------------
>
> Key: OOZIE-2777
> URL: https://issues.apache.org/jira/browse/OOZIE-2777
> Project: Oozie
> Issue Type: Bug
> Reporter: Peter Cseh
> Assignee: Peter Cseh
> Attachments: OOZIE-2777-1.patch, OOZIE-2777-2.patch,
> OOZIE-2777-3.patch, OOZIE-2777-4.patch, OOZIE-2777-5.patch,
> OOZIE-2777-7.patch, OOZIE-2777-8.patch, OOZIE-2777-9.patch
>
>
> OOZIE-1642 introduced a workaround for DataOutputStream's 64k limit for
> Strings.
> We've encountered the same error when a config-default.xml is larger than the
> limit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
