CSR review request JDK-8233621, Mismatch in jsse.enableMFLNExtension property name
Xuelei Fan
xuelei.fan at oracle.com
Fri Nov 8 16:59:29 UTC 2019
It looks like that we cannot get a consensus about the CSR. I will
withdraw this CSR, and go forward with an update that does not need to
update the CSR or doc.
Thanks,
Xuelei
On 11/7/2019 5:29 PM, Xuelei Fan wrote:
> If there are two properties used for the same function, we need to
> respect one and discard another one. Which one should be respected? As
> could be confused.
>
> For example, property "pro-A" is set to "value-A", and property "pro-B"
> is set to "value-B", which value should be used? If "pro-A" is not set,
> while "pro-B" is set to "value-B", should "value-B" be used? We may be
> able to workaround and documentation be behaviors clearly. But it might
> be not necessary if there is a acceptable one-property-name solution.
>
> Xuelei
>
> On 11/7/2019 1:32 PM, Sean Mullan wrote:
>> On 11/7/19 12:34 PM, Xuelei Fan wrote:
>>> As the property has a default value, so there is a problem to use two
>>> properties for the same purpose. We don't really know if an
>>> application uses the misspelled name, or intended to use the default
>>> value.
>>
>> But you know if an application has set the property (the misspelled
>> one or the correct one), so I don't see the issue, but maybe I am
>> missing something. Can you be more specific, or give an example where
>> it would be an issue?
>>
>> --Sean
>>
>>>
>>> For the current applications, if the implementation name get used,
>>> okay, they get the expected behavior if we change to use the impl
>>> name, and no worries. However, if we change to use the doc name, the
>>> behavior get changed, and problems come out.
>>>
>>> For the current applications, if the doc named get used.
>>> Applications may expect it to work, but actually not. If we change
>>> to use the impl name, the application still does not work, no
>>> additional risks. If we change to use the doc name, the
>>> configuration works but the application behavior also get changed
>>> (although it is the expected behavior).
>>>
>>> I think the risk is pretty low if change to use the impl name.
>>>
>>> Xuelei
>>>
>>> On 11/7/2019 8:46 AM, Sean Mullan wrote:
>>>> I guess another option is to not change the name that is used in the
>>>> docs, but change the code to look for both properties, trying the
>>>> docs name first, and then the misspelled name.
>>>>
>>>> Not great, but probably the safest and least disruptive option.
>>>>
>>>> --Sean
>>>>
>>>> On 11/5/19 8:07 PM, Xuelei Fan wrote:
>>>>> I understand your points. Between using the doc name and the code
>>>>> name, I think using the code name is a little bit safer if someone
>>>>> really use the impl name. However, just a little bit. I’m open to
>>>>> use the doc name if we could get an agreement.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 5, 2019, at 4:32 PM, Anthony Scarpino
>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>
>>>>>> I understand the desire to change this, but are we sure the doc
>>>>>> should be changed instead of the property? I would tend to
>>>>>> believe users code to the doc and don’t notice it wasn’t
>>>>>> working. Not reading the source code and code to that
>>>>>> implemented name. Otherwise I’d assume someone would have filed a
>>>>>> bug already in the 2yrs.
>>>>>>
>>>>>> I don’t want us to support two properties, I’m just not confident
>>>>>> which way is right.
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>>> On Nov 5, 2019, at 4:00 PM, Xuelei Fan <xuelei.fan at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> May I have the CSR reviewed?
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8233652
>>>>>>>
>>>>>>> The system property, "jsse.enableMFLNExtension", was introduced
>>>>>>> in JDK 9 (See JSSE Reference Guides). However, the implementation
>>>>>>> code uses "jsse.enableMFLExtension" (without 'N') instead.
>>>>>>>
>>>>>>> As the system property may have been used in practice, it may be
>>>>>>> better to change the CSR and doc accordingly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Xuelei
>>>>>>
>>>>>
More information about the security-dev
mailing list