[9] RFR: 8173390: Investigate SymbolTable in SAXParser

[huizhe wang]

Looks good to me.

Thanks,
Joe

On 2/15/2017 3:56 PM, Aleks Efimov wrote:
> Hi Joe,
>
> Thank you for your suggestions. New webrev can be found here:
> http://cr.openjdk.java.net/~aefimov/8173390/9/01
>
> Hi Daniel,
> You're right that assertNotSame suites better here, i.e. it has nice 
> output in case of failure. Because of that I removed the 
> sout.println's from the test too.
>
> With Best Regards,
> Aleksej
>
>
> On 15/02/17 20:16, huizhe wang wrote:
>> Hi Aleksej,
>>
>> I just realized there were other dependencies on the SymbolTable 
>> instance initialized in the constructor (line 575 in your new code), 
>> which was probably why you kept the code from 574 through 579 after 
>> adding new SymbolTable for each parsing process (850 - 854). As a 
>> result, the SymbolTable will be created twice for the first parsing 
>> process. One way to solve the issue is to check whether the 
>> SymbolTable instance is new, or otherwise adding a reset function 
>> would work as well. In both cases, there will be a bit change to the 
>> SymbolTable to expose the count. What would you think?
>>
>> Thanks,
>> Joe
>>
>> On 2/15/2017 8:31 AM, Aleks Efimov wrote:
>>> Hi,
>>>
>>> Please, help to review the change required by JAXWS-RI code [1]: 
>>> SAXParser needs to reset internal SymbolTable to enable pooling of 
>>> parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is 
>>> currently under review [2]) doesn't provide a workaround to reset 
>>> the symbol table (it was done to remove module dependency on Xerces 
>>> internal classes). So the solution is to reset the SymbolTable 
>>> during SAXParser reset. The webrev with the changes and simple test 
>>> that reproduces SAAJ-RI behavior:
>>>     http://cr.openjdk.java.net/~aefimov/8173390/9/00/
>>>
>>> The fix was tested with all JDK/JCK (JAX[P|B|WS] related tests. No 
>>> failures observed.
>>>
>>>
>>> Thank you,
>>> Aleksej
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8173390
>>> [2] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-February/046386.html
>>>
>>
>