Describe the bug
The class loading of providers changed if an Authenticator parameter is set for the call of Session.getInstance(Properties, Authenticator). This is not documented and completely unexpected. It has cost me days to understand why with OAuth and Authenticator in production the provider was not loaded.
Class<?> cl;
if (authenticator != null) {
cl = authenticator.getClass();
} else {
// Use implementation class, because that class loader has access to jakarta.mail module and implementation resources
cl = streamProvider.getClass();
}
Expected behavior
The same class loading behavior with and without Authenticator. The minimum is to documented this behavior.
For consistence with other parts of the API the context class loader should be used.
Describe the bug
The class loading of providers changed if an Authenticator parameter is set for the call of
Session.getInstance(Properties, Authenticator). This is not documented and completely unexpected. It has cost me days to understand why with OAuth and Authenticator in production the provider was not loaded.Expected behavior
The same class loading behavior with and without Authenticator. The minimum is to documented this behavior.
For consistence with other parts of the API the context class loader should be used.