Skip to content
New issue

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

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

Already on GitHub? # to your account

ResourceConfig not properly using specified ClassLoader #4304

Closed
d0x7 opened this issue Oct 28, 2019 · 0 comments
Closed

ResourceConfig not properly using specified ClassLoader #4304

d0x7 opened this issue Oct 28, 2019 · 0 comments
Milestone

Comments

@d0x7
Copy link
Contributor

d0x7 commented Oct 28, 2019

The issue is slightly related to #3227, but not exactly. In #3227 the issue is happening when loading jersey via a different ClassLoader, my issue is happening when routes/packages to scan use a different ClassLoader than the one jersey is loaded with. Eventually also related to #3515, which does not fix my problem.

Currently, you may register a package via ResourceConfig#packages, but if the package is not found, it's just ignored without an error or notice.
If you register a package using ResourceConfig#registerFinder (using the "default" PackageNamesScanner with a custom ClassLoader specified), the classes/routes are discovered but an error will raise once it'll try to load the class, because it's loaded using the default ClassLoader anyways and not the one, specified in PackageNamesScanner. I know you may specify a ClassLoader in the ResourceConfig using #setClassLoader itself, but then that ClassLoader will be used for all packages, I need one ClassLoader per package.

I already fixed this issue and will create a PR in just a second. I hope you will merge that PR because I don't wanna maintain my own fork of jersey. As you can see in the PR, it's currently only for the PackageNamesScanner class. I also thought about adding a method to the ResourceFinder interface, but discarded that because I don't know whatelse uses the ResourceFinder class and whether a getClassLoader method would be useful there - I don't guess so, that's why I did it the way I did.

@jansupol jansupol closed this as completed Nov 1, 2019
@jansupol jansupol added this to the 2.30 milestone Nov 1, 2019
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants