dropwizard: @Context or @Session injection not working in ContainerRequestFilter
Hi,
According to Jersey people, this (at least with @Context) should be supported since Jersey 2.4 (see JERSEY-1960 but I’m trying with dropwizard 0.9.3 and and the context simply does not get injected. I also tried with the dropwizard’s @Session annotation but it’s the same.
Is that normal or is there a bug somewhere?
Note: my filter is registered via AuthDynamicFeature (because it’s an alternative authentication filter based on the content session, maybe it’s not the best way to do that?).
Thanks!
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 30 (21 by maintainers)
Commits related to this issue
- Allow for passing a filter as a class Jersey does not behave exactly the same when registering object and class during a DynamicFeature configuration. This commit allows for both behaviour to be exp... — committed to victornoel/dropwizard by victornoel 8 years ago
- Allow for passing a filter as a class Jersey does not behave exactly the same when registering object and class during a DynamicFeature configuration. This commit allows for both behaviour to be exp... — committed to victornoel/dropwizard by victornoel 8 years ago
- Allow for passing a filter as a class Jersey does not behave exactly the same when registering object and class during a DynamicFeature configuration. This commit allows for both behaviour to be exp... — committed to victornoel/dropwizard by victornoel 8 years ago
Most common mistake is using object instance instead of class.
Instead of registering a object instance like this
environment.jersey().register(new AuthDynamicFeature(new ExampleAuthFilter()));use the class while registering the filter (so that @Context injection will work as expected),
environment.jersey().register(new AuthDynamicFeature(ExampleAuthFilter.class));I use dropwizard:1.0.5 and what is actual solution to use:
@Context HttpServletRequest request;I was trying but request is always null
@abhishek199-dhn here is not the best place to solve Jersey injection problems, so I would recommend to ask directly on jersey’s discussion groups.
That being said, I’m not sure how to fix your problem. One solution would be to register a class and put its dependencies in an hk2
AbstractBinderregistered also into jersey… but it’s not very elegant, true.I made a PR (#1715) to finally close this issue 😃
Actually @psamsotha, it seems that
PolymorphicAuthDynamicFeaturealready works with classes (but not objects), so the needs for passing object may arises, but the probability seems low.I would have like to make a PR for
AuthDynamicFeaturebut I’m going to be unavailable for a month, and honestly, I decided to stop using thedropwizard-authpackage (I preferred to integrate pac4j with dropwizard, if it is successful I will make a bundle of it I think), but if you want to wait that time, I will do it gladly 😃Hi, I’m back on this:
After some reading (mainly of the documentation of
Configurable.register(java.lang.Object component)), actually, there should be support for injection of the@Contextannotated members of theContainerRequestFilter(at least supported by default of course) if it was registered byAuthDynamicFeatureas a class and not an instance.So it would be interesting if
AuthDynamicFeaturewould support passing a class instead of an instance in the constructor (maybe both exclusive cases should be available even).I tested it and it does work.
What do you think?