RFR: JAXP 1.5 for JDK8/7u40: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown
huizhe wang
huizhe.wang at oracle.com
Thu Jul 4 20:25:39 UTC 2013
On 7/4/2013 3:28 AM, Alan Bateman wrote:
> On 04/07/2013 10:11, huizhe wang wrote:
>>
>> Daniel has helped adding many tests. The 1st one of the two scenarios
>> above are tested. It appeared that the properties set through the
>> factory or parser are always taken into account the last, therefore
>> take preference in consistence with the spec. We still have the 2nd
>> scenario to test. But here's the latest webrev:
>>
>> http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
>>
>> It also uses the SourceVersion Joe suggested to determine the version
>> of the JDK.
>
> We can't have a dependency on SourceVersion here as it would cause
> problems for modules. I assume it will also break the profiles build
> because the javax.lang.model API is not in compact1 or compact2. So I
> think this need to be reverted to just look at the java.version
> property and I would suggest keeping it simple -- ie: assume the long
> standing format as that cannot be changed without causing wide-spread
> breakage.
Reverted back to the original code:
http://cr.openjdk.java.net/~joehw/jdk8/8016648/webrev/
The code split the version number and look at the 1st or 2nd element, it
thus works for both the current format and the proposed one, e.g. for
1.7.0, it compares with the 2nd element, and for the proposed
MAJOR.MINOR.FU.*, the 1st or MAJOR.
>
> I skimmed over the rest of the webrev and don't see any other issues.
> It's great to hear that Daniel is helping to add tests as that is key
> to having confidence with these changes.
The last scenario to work on is if FSP is set on the Validator instead
of SchemaFactory. With that, I'm looking at refactoring the way
properties are represented so that they carry state. It would then be
cleaner to pass them from SchemaFactory over to Schema and then
Validator. It's a bit of work. Fortunately, we only have three of them
to deal with.
-Joe
>
> -Alan.
>
More information about the core-libs-dev
mailing list