Jersey-like parameter injection

102 views
Skip to first unread message

Derrick

unread,
Feb 3, 2012, 3:26:40 AM2/3/12
to google...@googlegroups.com
I would like to inject values dependent on the class they are being injected into:

package x.y.z

public class Foo {
     @Inject
       Foo ( @Settings("param1") String x ) {
       }

where @Settings("param1")  is automatically (effectively) rewritten as @Named("x.y.z.Foo.param1") in this context and rewritten as @Named("a.b.c.Bar.param1") in the following content:

package a.b.c

public class Bar {
     @Inject
       Bar ( @Settings("param1") String x ) {
       }

Can I accomplish this with Guice 3.0?  with Guice 4.0 trunk?  as an extension to Guice 4.0?

Thanks!
 

Igor Petrouk

unread,
Feb 7, 2012, 3:08:27 AM2/7/12
to google...@googlegroups.com
Hi.

Take a look at TypeListener and MembersInjector. There is an example on how to do custom logging injection.

2012/2/3 Derrick <derric...@gmail.com>
 

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-guice/-/5lY8_VvUONoJ.
To post to this group, send email to google...@googlegroups.com.
To unsubscribe from this group, send email to google-guice...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.

Tim Boudreau

unread,
Oct 5, 2012, 12:59:22 AM10/5/12
to google...@googlegroups.com
On Friday, August 31, 2012 2:27:16 AM UTC-4, Derrick wrote:
I understand how I could perform member injection to achieve my desired result.  However, I'd prefer to use only constructor injection.  If I could use constructor injection, then the constructor could be used with our without Guice. 

One idea is to rewrite the fields of the annotations of constructor parameters.  In the example below, x.y.z.Foo's constructor would be rewritten by a Guice listener of some sort as:

I agree about wanting only constructor injection.

Out of curiousing, since it seems your @Settings is identical to @Named, why not just use @Named?

If you're setting up the bindings that would be used by @Named, you could just do your own binding to @Settings - just grab the Properties or whatever you're binding strings with (I assume it's not done explicitly in code), write a correct implementation of @Settings, iterate the keys and bind it.  An example of how to do that sort of thing starts around line 497 in this file:

-Tim
Reply all
Reply to author
Forward
0 new messages