The GSS and SASL changes look fine to me.
Two small questions:
1. If the change in java.security.jgss/share/classes/module-info.java is
unavoidable, can we create a sub-package for this single class so that we only
need to export it? Or, do you think we can define the sub-class inside
GssKrb5C
Hello All,
Thank you for review.
> 1. If the change in java.security.jgss/share/classes/module-info.java is
> unavoidable, can we create a sub-package for this single class so that we
> only need to export it?
As suggested by Max I’ve moved TlsChannelBindingImpl class into sub-package, so
mod
> On Jul 3, 2020, at 7:32 PM, Alexey Bakhtin wrote:
>
> Hello All,
>
> Thank you for review.
>
>> 1. If the change in java.security.jgss/share/classes/module-info.java is
>> unavoidable, can we create a sub-package for this single class so that we
>> only need to export it?
>
> As suggest
> I would suggest removing it. At least for the SASL GSS-API mech, it seems the
> GSSContext object will not be leaked and no one has a chance to call
> setChannelBinding again on it.
>
> There is no spec saying setChannelBinding() can only be called once, so I'd
> rather we don't enforce that
Hi Valerie,
Thanks for your comments! They sparked off a lot more investigation on my end.
I created a test provider and could not reproduce the issue. That led me to
investigate how our provider was being installed. We use our own internal
Initializer() class to install providers in v
