[icedtea-web] RFC: PR766 javaws fails to parse an <argument> node that contains CDATA
Omair Majid
omajid at redhat.com
Thu Sep 22 12:49:46 PDT 2011
On 09/22/2011 03:19 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com> [2011-09-22 14:55]:
>> On 09/22/2011 01:48 PM, Deepak Bhole wrote:
>>> * Omair Majid<omajid at redhat.com> [2011-09-21 16:49]:
>>>> On 09/19/2011 01:44 PM, Omair Majid wrote:
>>>>> On 09/19/2011 01:01 PM, Deepak Bhole wrote:
>>>>>> * Omair Majid<omajid at redhat.com> [2011-09-16 18:03]:
>>> ...
>>> ...
>>>>> If you mean the parser in icedtea-web chokes on CDATA sections (or
>>>>> handles these CDATA sections differently) - as shown in the test results
>>>>> - then yes, that might be a problem. As stated above I intend to write a
>>>>> patch with additional tests for this. As an additional precaution, I
>>>>> would like to avoid backporting this patch to any of the release branches.
>>>>>
>>>>
>>>> So I spent some time looking into it and it turns out that the
>>>> version of NanoXML that we use does not support mixed content [1] -
>>>> so it's not a problem with using CDATA sections, it's a problem with
>>>> intermixing text and elements.
>>>>
>>>> The good news is that JNLP files should not contain mixed content.
>>>> Nothing the Oracle's docs [2] suggests that mixed content can occur
>>>> in JNLP files. Perhaps another thing to consider is that we have not
>>>> seen any bugs filed about problems in jnlp files caused by mixed
>>>> content. So this should not occur in practice.
>>>>
>>>> Of course, I could implement this, but it turns out that
>>>> NanoXML/Lite (which is what was embedded in netx) does not support
>>>> that pretty much by design [3]. NanoXML/Java does support that [3],
>>>> but I am hesitant to swap out our parser like this. And if I were
>>>> swapping out the parser, I would rather use a parser meant to handle
>>>> malformed XML documents - like tagsoup [4] - along with a
>>>> well-tested XML parser.
>>>>
>>>> In fact, after considering the matter, I would like push just the
>>>> two patches I posted earlier in this thread and close the bug.
>>>>
>>>> Any thoughts or comments?
>>>>
>>>
>>> Sorry if I'm missing something, but don't we still need a patch to
>>> JNLPMatcher to make it not fail when presented with CDATA?
>>>
>>
>> I suppose I was not very clear. JNLPMatcher - actually XMLElement
>> (our parser) - fails when presented with mixed content. Whether that
>> content is just plain text or text escaped using CDATA sections
>> doesnt matter. The attached patch converts CDATA section to plain
>> text and the test still fails (after apply the two patches I posted
>> earlier in the thread).
>>
>> JNLPMatcher (and XMLElement) work when text is escaped using CDATA
>> sections in the absence of mixed content.
>>
>> Since we have never seen failures caused by mixed content using
>> plain text, I suppose we can assume that failures wont be caused by
>> mixed content containing text escaped using CDATA sections.
>>
>> Hope that clears things up.
>>
>
> Ah, sorry. I thought it didn't work at all. Didn't realize that it was
> just mixed content that made it fail.
>
> Okay then, I am fine with these patches in HEAD and closing the issue.
>
Done. Thanks for reviewing!
Cheers,
Omair
More information about the distro-pkg-dev
mailing list