-
Notifications
You must be signed in to change notification settings - Fork 610
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
SOLR-16840: Workaround HK2 DI bug #1726
SOLR-16840: Workaround HK2 DI bug #1726
Conversation
Prior to this commit many v2 invocations would succeed but log scary looking stacktraces to Solr's console log. This was because of a bug in how Jersey creates and cleans up "RequestScoped" objects. (See Jersey#3503 for more details.) This commit works around the bug by changing how several "factory" classes obtain a "ContainerRequestContext": switching away from DI and towards looking up the CRC more explicitly using a "ServiceLocator".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Finally learned what the hk2 prefix is. https://en.wikipedia.org/wiki/GlassFish_HK2
Just out of curiosity, are we behind on our version of Glassfish and HK2? I.e, are we establishing a pattern of not upgrading and then having to work around things? If/when the bug in HK2 gets fixed, how will we know to eliminate our workaround? DOn't we sometimes annoate code with a bug url?
So the Github Issue that Jason linked has been open for 6 years, and not closed. So definitely not an upgrade issue. Yeah we can probably link the Issue url in a comment somewhere, so this is documented in the code. Good idea |
No, we're not behind on hk2 - it's just a long standing bug I guess. I've added a comment as you guy suggested to we can use more conventional injection when the bug does eventually get fixed. |
Prior to this commit many v2 invocations would succeed but log scary looking stacktraces to Solr's console log. This was because of a bug in how Jersey creates and cleans up "RequestScoped" objects. (See Jersey#3503 for more details.) This commit works around the bug by changing how several "factory" classes obtain a "ContainerRequestContext": switching away from DI and towards looking up the CRC more explicitly using a "ServiceLocator".
https://issues.apache.org/jira/browse/SOLR-16840
Description
Prior to this commit many v2 invocations would succeed but log scary looking stacktraces to Solr's console log. This was because of a bug in how Jersey creates and cleans up "RequestScoped" objects. (See Jersey#3503 for more details.)
Solution
This commit works around the bug by changing how several "factory" classes obtain a "ContainerRequestContext": switching away from DI and towards looking up the CRC more explicitly using a "ServiceLocator".
Tests
Manual testing to verify that the warning stacktraces no longer appear in Solr's console logging. Automated tests continue to pass.
Checklist
Please review the following and check all that apply:
main
branch../gradlew check
.