-
Notifications
You must be signed in to change notification settings - Fork 357
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
ClassCastException if loaded by different class loaders in OSGi runtime #5036
Comments
I do not think this is a proper solution:
The issue seems to be that a single classloader sees 2 versions of Jersey, but the classloaders should be restricted to a single version of Jersey (as well as all dependencies). To me, when you add a check on these two places, you will get a similar ClassCastException only a little longer, there would be many places where you would get the same issue. HK2 proxy is one big example where two classloaders make issues, the injections likely will stop working. Perhaps you could make your OSGi headers of your app to require the EXACT version of Jersey instead of range of versions? |
We are running under the Eclipse runtime, so the dependency versions are defined in the manifest. In our manifest, there already is an EXACT version (3.0.4) for Jersey:
The other version in the Eclipse platform is 2.30.1 I do not think that issue is that single classloader sees 2 versions of Jersey. As it says in the exception, the problem is that there are 2 classloaders: I traced all the Jersey bundles registered by the In our case, we are creating only the Jersey client and I have tested my suggested changes, and did not hit any other issue. |
First, one correction. The But it does not change a fact that Jersey's You mentioned that it is not a proper solution to do the class cast check only on those 2 places. I have tested a solution where I put the check into the |
Updating Ideally, |
Thanks for the suggestion with the |
I was trying to implement the suggestion but to me it does not seem feasible. Anyway, In my opinion the check in the Maybe I can open a PR so we can discuss the solution further. |
Description
Our code (Eclipse plugin) using Jersey client is running in OSGi runtime (Eclipse IDE). There are some Eclipse platforms that contain version of Jersey libraries different from that required by our plugin. Therefore our plugin puts the required version to the classpath. However, each Jersey version is then loaded by a different class loader. There are two places where this is causing problems:
InjectionManagerFactory
inorg.glassfish.jersey.internal.inject.Injections
org.glassfish.jersey.model.internal.CommonConfig
The problem is that in those places and in this scenario, cast is done using classes from different class loaders resulting in
ClassCastException
stopping the request completely. We think these casts could be avoided and the request should be able to proceed.Lookup of the InjectionManagerFactory
Note: I have truncated the exception stack trace to show only the Jersey stuff because it is quite long with all the Eclipse stuff.
Exception:
Code snippet:
jersey/core-common/src/main/java/org/glassfish/jersey/internal/inject/Injections.java
Lines 72 to 93 in 8f7fa99
Configuring of AutoDiscoverable
Note: I have truncated the exception stack trace to show only the Jersey stuff because it is quite long with all the Eclipse stuff.
Exception:
Code snippet:
jersey/core-common/src/main/java/org/glassfish/jersey/model/internal/CommonConfig.java
Lines 582 to 629 in 8f7fa99
Suggested solution
I have tested a solution with our code that will simply check in both places if the cast can be done. Do you think the suggested solution is OK? Or is there some other way to solve this situation?
I can open a PR if you think the solution is OK.
The text was updated successfully, but these errors were encountered: