-
Notifications
You must be signed in to change notification settings - Fork 355
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
ResourceConfig not properly using specified ClassLoader #4304
Milestone
Comments
This was referenced Jun 26, 2021
This was referenced Aug 5, 2021
This was referenced Aug 30, 2021
1 task
This was referenced Oct 4, 2021
This was referenced Oct 18, 2021
This was referenced Oct 21, 2021
Merged
Merged
Closed
This was referenced Oct 21, 2021
1 task
1 task
This was referenced Mar 7, 2022
This was referenced Mar 15, 2022
This was referenced Apr 17, 2022
This was referenced May 3, 2022
1 task
This was referenced Oct 19, 2022
1 task
1 task
1 task
1 task
This was referenced Apr 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 inPackageNamesScanner
. I know you may specify a ClassLoader in theResourceConfig
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 theResourceFinder
interface, but discarded that because I don't know whatelse uses the ResourceFinder class and whether agetClassLoader
method would be useful there - I don't guess so, that's why I did it the way I did.The text was updated successfully, but these errors were encountered: