Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Session.getService does not use proper classloader in OSGI environment #631

Closed
mnlipp opened this issue Oct 22, 2022 · 2 comments · Fixed by #703
Closed

Session.getService does not use proper classloader in OSGI environment #631

mnlipp opened this issue Oct 22, 2022 · 2 comments · Fixed by #703
Assignees

Comments

@mnlipp
Copy link
Contributor

mnlipp commented Oct 22, 2022

Describe the bug
Even after fixing service loader related 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
        }
@mnlipp mnlipp changed the title Service.getService does not use proper classloader in OSGI environment Session.getService does not use proper classloader in OSGI environment Oct 23, 2022
mnlipp added a commit to mnlipp/jgrapes that referenced this issue Oct 23, 2022
@jbescos
Copy link
Member

jbescos commented Nov 8, 2022

@mnlipp this was merged: #633

Can we close this?

@mnlipp
Copy link
Contributor Author

mnlipp commented Nov 8, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants