Hi,
I'd like to propose a fix for JDK-8253451 [1] performance regression.
Webrev.00:
* http://cr.openjdk.java.net/~mbalao/webrevs/8253451/8253451.webrev.00
As explained in [1], the idea for the fix is to optimize the regexp
string for the most common group and decimal separator characters
As described in JDK-8259319 [1], this fix proposal is to set proper access
permissions so the SunPKCS11 provider can create instances of SunJCE classes
when a Security Manager is installed and the fallback scheme is used.
No regressions found in jdk/sun/security/pkcs11 tests category.
--
[1] -
tests category.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319
Martin Balao has updated the pull request incrementally with two additional
commits since the last revision:
- Limit P11Util::getProvider privileged access to the required
'accessClassInPackage' Runtim
On Thu, 7 Jan 2021 19:29:29 GMT, Valerie Peng wrote:
>> As described in JDK-8259319 [1], this fix proposal is to set proper access
>> permissions so the SunPKCS11 provider can create instances of SunJCE classes
>> when a Security Manager is installed and the fallback scheme is used.
>>
>> No
On Fri, 8 Jan 2021 19:35:47 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Limit P11Util::getProvider privileged access to the required
>> 'accessClassInP
On Thu, 7 Jan 2021 21:23:55 GMT, Sean Mullan wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Limit P11Util::getProvider privileged access to the required
>> 'accessClassInP
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback schem
I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the
state previous to JDK-8160768, where an authentication failure stops from
trying other LDAP servers with the same credentials [1]. After JDK-8160768 we
have 2 possible loops to stop: the one that iterates over
On Wed, 10 Nov 2021 12:58:13 GMT, Aleksei Efimov wrote:
>> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
>> the state previous to JDK-8160768, where an authentication failure stops
>> from trying other LDAP servers with the same credentials [1]. After
>>
On Wed, 10 Nov 2021 12:58:13 GMT, Aleksei Efimov wrote:
>> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
>> the state previous to JDK-8160768, where an authentication failure stops
>> from trying other LDAP servers with the same credentials [1]. After
>>
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
> the state previous to JDK-8160768, where an authentication failure stops from
> trying other LDAP servers with the same credentials [1]. After JDK-8
On Wed, 17 Nov 2021 20:04:50 GMT, Martin Balao wrote:
>> Hi Martin,
>>
>> The change looks reasonable to me.
>> I would suggest having a CSR logged for this change due to the following
>> [behavioral
>> incompatibility](https://wiki.openjdk.java.ne
On Thu, 16 Dec 2021 01:23:11 GMT, Martin Balao wrote:
>> Hi @AlekseiEfimov
>>
>> Can you please review the CSR [1]?
>>
>> Thanks,
>> Martin.-
>>
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959
>
>> @mar
On Tue, 8 Feb 2022 13:41:28 GMT, Martin Balao wrote:
>>> @martinuy This pull request has been inactive for more than 4 weeks and
>>> will be automatically closed if another 4 weeks passes without any
>>> activity. To avoid this, simply add a new comment to the p
On Wed, 9 Feb 2022 11:10:14 GMT, Michael Osipov wrote:
>>> @martinuy, I am the reporter of JDK-8160768. Regarding this PR, isn't
>>> everything protocol related a fail-fast issue? E.g., if the socket is up
>>> and running, but the LDAP message is rejected can we assume that all
>>> subsequent
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
> the state previous to JDK-8160768, where an authentication failure stops from
> trying other LDAP servers with the same credentials [1]. After JDK-8
On Wed, 9 Feb 2022 19:12:34 GMT, Daniel Fuchs wrote:
> The concerns are two folds:
>
> * without a regression test, you have to trust that the source changes
> actually work, and there's typically no verification possible
> * without a regression test, the next refactoring change in this area
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to
> the state previous to JDK-8160768, where an authentication failure stops from
> trying other LDAP servers with the same credentials [1]. After JDK-8
On Thu, 10 Feb 2022 15:25:09 GMT, Aleksei Efimov wrote:
>>> The concerns are two folds:
>>>
>>> * without a regression test, you have to trust that the source changes
>>> actually work, and there's typically no verification possible
>>> * without a regression test, the next refactoring change
19 matches
Mail list logo
