Jakarta Mail erroneously assumes that classes can be loaded from Thread#getContextClassLoader

[jmehrens]

#665

[jmehrens]

@lukasj @jbescos Here is my attempt at fixing this error. Basically this change probes various classloaders in order of preference to find the provider that is usable in the caller classloader. Let me know what you think. For sure it seems suspect to me that I'm not using a PrivilegedAction to fetch the classloader. Thoughts? Testing this change is not going to be easy.

[jbescos]

LGTM

[jmehrens]

@jbescos Fixed issues with:

• privileged actions when needed.
• Unify API so null classloader means use system classloader matching Service API.
• Added a simple test case.
• Found a bug where hard coded implementation classes were the wrong package name.

[basil]

I have reproduced the issue interactively in Jenkins with the Gmail SMTP server at HEAD with commit 6c9ac50 and verified that the issue is resolved with this PR.

[basil]

A merge and release of this PR would unblock our upgrade to recent versions of Mail API and allow us to resolve issues like JENKINS-70627.

[jmehrens]

I have reproduced the issue interactively in Jenkins with the Gmail SMTP server at HEAD with commit 6c9ac50 and verified that the issue is resolved with this PR.

Thanks @basil for testing. I'm surprised this worked as is with out a similar fix to JAF. Either way I'll try to get this merged.

[basil]

I'm surprised this worked as is with out a jakartaee/jaf-api#144. Either way I'll try to get this merged.

I have been working around the problem in Jakarta Activation with https://github.com/jenkinsci/jakarta-mail-api-plugin/tree/5a95bb71b308c7ba2dab277deffb36dfe1e03c8c/src/main/java/io/jenkins/plugins/jakarta/activation for years now. But I have no workaround for this issue in Jakarta Mail.