Access to injection point annotation in provider?

[Mark Addleman]

I'd like to gain access to an annotation at the injection point within a provider.  The idea is that at startup, clients dynamically register names of objects.  After startup, clients can gain access to these objects using the @Named annotation.  The provider would use the value of @Named to find the named object.

Example client code:
@Inject
public Constructor(@Named("my-object-name") SomeClass object) {...}

Provider code that I'd like to write:
public ObjectProvider {
   public SomeClass get(Annotation a) {
      // lookup value of a and return it
   }
}

How can I accomplish this?  I'm sure I'm missing something obvious in the docs.

Thanks

[Alen Vrečko]

In short you cannot inject the injection point see

http://code.google.com/p/google-guice/issues/detail?id=27

But take a look at http://code.google.com/p/google-guice/wiki/CustomInjections

Feel free to search the mailing list as this was discussed before.

Cheers
Alen

[Mark Addleman]

Thanks.  I discovered TypeListeners but can't puzzle how to get them to alter the injected object.  I'll go through the group archives to find examples.

[Mark Addleman]

The key problem with TypeListeners is they can't find how to use them for constructor injection.  Another poster has a similar problem.

Is there an example of this?

[Noctarius]

Am 22.02.2012 18:19, schrieb Mark Addleman:
> The key problem with TypeListeners is they can't find how to use
> them for constructor injection. Another poster has a similar problem.
>

You cannot use TypeListeners for constructor injection. You need to
use ProvisionListener from Guice 4 to intercept constructor injection.
An example how to use it can be found here:
https://bitbucket.org/noctarius/guiceidentityinjection/src/014f6cb8fcc0/src/main/java/com/google/inject/identityinjection/IdentityProviderFactory.java

Maybe there are other ways to implement it.

Cheers
Noc

> Is there an example of this?

> --
> 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/-/kbxm1fzADlcJ.
> 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.

[Alen Vrečko]

Maybe you can restructure your program differently.

My first thought was why use Strings to identify things?

This implies clients know ahead of time which Strings to look for. Why
don't you use interfaces instead?

Imho the whole point of Guice is that Class definition itself serves
as injection identity (qualifier) with optional annotation.

It looks to me as if you want to do some lightweight pluggable stuff.

I'd have

ServiceX-API.jar
ServiceX-impl.jar (has ServiceLoader entries for Guice Module)
.....

have clients of ServiceY depend on ServiceX-API.jar and put proper
require bindings in ServiceY-impl.

In runtime just get all Guice Modules of the various Service_-Impls
via ServiceLoader and register them.

Using something like that it just works OOTB hassle free.

Cheers
Alen

On Feb 19, 9:01 pm, Mark Addleman <markaddle...@gmail.com> wrote:

[Mark Addleman]

That's the crux of my problem:  I've got my own pluggable extension framework built on top of Guice and the semantics don't quite match closely enough:  I want to use strings to match up extensions with their clients and it doesn't quite fit Guice's view of the world (but it's closely enough that it *should* work! ;) )

Anyway, I have restructured my use of Guice to get it close enough to what I want.  Unfortunately, there's still a bit of boilerplate that I can't quite get rid of (I'm requirement extension writers to boilerplate a particular provider subclass) but it's not too bad.

Thanks to all for information!