-
Notifications
You must be signed in to change notification settings - Fork 33
Guice binding annotations not working #34
Comments
@mumrah: Do you have @Override
protected void configure() {
bind(FooResource.class);
bind(BarResource.class);
} I wonder if one of the resources is being initialized by HK2. |
I'm seeing what might a similar issue -- intermittently an incorrect binding is injected into a resource. (generally, I have to restart my application to get different behavior) I'm trying to inject a JDBI DBI object into my resource. I have two annotated bindings for DBI Providers in my injector, one for a persistent database (@DbPersist), another for a in-memory database (@DbMem)
Most of the time, the correct DBI is injected. Intermittently the wrong DBI is injected. my stack: Dropwizard 0.8.5, dropwizard-guice 0.8.4, jersey2-guice 0.10, guice 4.0 I can debug where my DBI provider is being called, and from the callstack it looks like the call from jersey into the GuiceServiceLocator knows the source annotation on the constructor (@DbMem). But, 16+ calls later the call from GuiceBindingDescriptor into the Guice injector is asked for the DBI with the wrong binding annotation (@DbPersist) (continued spelunking) looking at it further... it seems like maybe it's happening during reflection, trying to get the constructor's parameters qualifiers... (more spelunking) in hk2-locator(2.4.0-b31), method (additional spelunking) I'm still not sure why it sometimes works, and sometimes doesn't. Adding @qualifier to my @DbMem / @DbPersist annotations appears to make my resource behave consistently. |
I'm having a very similar issue. I have two @provides for the same class, both with a custom annotation. So one @provides @foo, the other @provides @bar. The providers are in different modules, but both modules are part of the same application. However, sometimes it injects @bar where @foo is specified in the constructor! It's random and unpredictable. It's driving me crazy. I'm having to wrap things in small unique classes to get things to work. Near as I can tell, custom bindings are broken or have some race condition. |
@chriskessel I don't think anyone is injecting me :/ |
I'm seeing the same issue. I have an object annotated with |
@jylin Are you using Dropwizard and Guice? I created this issue with the dropwizard-guice library, which is where the problem seems to lie, I think... |
@chriskessel uhh? |
@chriskessel No, I'm not using any framework. I just have a main function that initializes guice, jersey and this bridge. |
I switched to using HK2 guice-bridge, and that seems to support Named injections better (though not perfect). |
I am experiencing a very similar issue. I have a module that binds various BindingAnnotations with string values. In a jersey module, I am injecting one of those BindingAnnotations. Each time I start the server, in jersey module, I am getting any of the values from the various BindingAnnotation at random. These BindingAnnotations work fine in other modules of the application. It's just the jersey module that's facing this issue. |
Copied from a Guice issue I previously filed (and closed): google/guice#966 (comment)
I have two modules that bind a set of strings like:
In FooModule:
And something similar in BarModule. Then elsewhere in the code I get these sets injected like:
and something similar in BarResource.
What I'm seeing is that one of these sets non-deterministically gets injected to both resource classes. E.g., the foo things end up in FooResource and BarResource, or vice-versa.
I have tried using the
@Named
binding annotation as well, with the same results. I have another multi-binding that uses different types instead binding annotations, and it is working fine.I'll try to come up with a test case later today/this week as time allows. I've worked around this for now by creating separate sub-types for the foo/bar things.
The text was updated successfully, but these errors were encountered: