Hi Joe, I think this is all OK
Best Lance On Oct 30, 2013, at 11:40 AM, huizhe wang wrote: > > On 10/30/2013 2:58 AM, Daniel Fuchs wrote: >> On 10/30/13 1:14 AM, huizhe wang wrote: >>> I updated the webrev to also fix the error message that showed the >>> actual number of attributes parsed rather than the limit itself. >>> >>> http://cr.openjdk.java.net/~joehw/jdk8/8024378/webrev/ >>> >>> Thanks, >>> Joe >> >> Hi Joe, >> >> Looks good to me. I see another change, which is that now reset() will >> also do: >> fInScanContent = false; >> But by the look of it I suspect it was a bug that it did not reset it >> previously? > > Yes. But since fInScanContent is always being reset to false after a scan, > this is actually redundant. It was previously in > reset(XMLComponentManager...) but not reset(PropertyManager ...). > > best, > Joe > >> >> best regards, >> >> -- daniel >> >> >>> >>> On 10/29/2013 4:49 PM, huizhe wang wrote: >>>> It appears the previous patch was one line short of supporting setting >>>> the JAXP's new property ElementAttributeLimit through the StAX >>>> factory, that is, resetting the variable in reset(PropertyManager >>>> propertyManager) as well. Other than that, I also moved the common >>>> reset items from reset(XMLComponentManager...) and >>>> reset(PropertyManager ...) to a new method called "resetCommon". >>>> >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk8/8024378/webrev/ >>>> >>>> The real change is to set the following in both reset methods, now in >>>> resetCommon: >>>> >>>> 663 fElementAttributeLimit = >>>> fSecurityManager.getLimit(XMLSecurityManager.Limit.ELEMENT_ATTRIBUTE_LIMIT); >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Joe >>>> >>> >> >
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
