Session.getService does not use proper classloader in OSGI environment

[mnlipp]

Describe the bug Even after fixing service loader related issues (https://github.com/eclipse-ee4j/mail/issues/630) services are not loaded in an OSGi environment.

To Reproduce Steps to reproduce the behavior:

1. Use patched jar(s)
2. Attempt to connect to imap provider.

Expected behavior Service with class name obtained from provider should load.

Cause of problem In an OSGi environment, the provider (obtained e.g. from imap.jar) has its own (bundle) classloader. This classloader is never tried when getting the service.

The code attempts loading with the context classloader and either the Session's classloader or -- if given -- the authenticator's classloader (why?). But the obvious option, using the classloader that loaded the provider, is not used.

What's missing is an attempt like:

        try {
            serviceClass = Class.forName(provider.getClassName(), false,
                provider.getClass().getClassLoader());
        } catch (ClassNotFoundException ex) {
            // ignore it
        }

[jbescos]

@mnlipp this was merged: https://github.com/jakartaee/mail-api/pull/633

Can we close this?

[mnlipp]

No. #633 was related to getting the provider (class). Once you have it, you use it to lookup (with Class.forName) the associated service class (the provider gives you the name only, not the class itself). This lookup by name works only if the class with the name is in the classpath being used for the lookup (second argument to Class.forName).

The classpath where the service class is most likely to be found is the provider's class path, and this is currently not tried. (Actually, the provider's class path is the only classpath where the service class can be expected to be found. All other attempts, especially trying the authenticator's classpath, seem arbitrary shots in the dark).