[Patch] custom annotation based injection points

[GoogleCodeExporter]

There are lots of standards and frameworks which define their own custom 
injection points. 
Here's a few off the top of my head; I'm sure there's many more out there...

JSR 250 & EJB3 defines @Resouce for injecting objects from JNDI
JPA defines @PersistenceContext for injecting JPA resources usually prebound to 
a transaction 
context etc
JAX-RS defines a number of them such as @PathParam, @HeaderParam, @Context etc
WebBeans defines @In
Stripes defines @SpringBean
Apache Camel defines @EndpointInject and @Produces

This patch makes it easy to implement these custom injection points in 
frameworks as follows; 
this example supports @Resource from JSR 250

{{{
@InjectionAnnotation(Resource.class)
public class ResourceProviderFactory<T> implements AnnotationProviderFactory<T> 
{
  private final Context context;

  @Inject
  public ResourceProviderFactory(Context context) {
    this.context = context;
  }

  public Provider<T> createProvider(AnnotatedElement member) {
    Resource resource = member.getAnnotation(Resource.class);
    Objects.nonNull(resource, "@Resource is missing!");
    String name = getJndiName(resource, member);
    return new Provider<T>() {...}
  }
}}}}

Rather than going into a long discussion in this issue, I'll bring it up on the 
mailing list and post 
a link here shortly...

Note that this patch also includes these patches...
http://code.google.com/p/google-guice/issues/detail?id=62
http://code.google.com/p/google-guice/issues/detail?id=78

given the amount of code I've changed for these 3 patches its been a bit tricky 
separating them 
out into different patches.

Mostly this patch involves changes to InjectionPoint and InjectorImpl along 
with the new interface AnnotationProviderFactory and annotation 
InjectionAnnotation along with a new test case in the 
jsr250 module called ResourceTest that tests out the injection of @Resource for 
field and 
method injection

Original issue reported on code.google.com by james.st...@gmail.com on 7 Oct 2008 at 3:13

Attachments:

• custom_annotation_injections.patch

[GoogleCodeExporter]

there's a discussion thread about this here : 
http://groups.google.com/group/google-
guice/browse_thread/thread/649f1a24c62a2bae

Original comment by james.st...@gmail.com on 7 Oct 2008 at 3:27

[GoogleCodeExporter]

Wow James, I think it is a really smart idea. This kind of puts Guice at the 
root of everything. =)

Original comment by latch...@gmail.com on 8 Oct 2008 at 3:30

[GoogleCodeExporter]

LOL - all part of my evil plan, mwa-ha-ha-ha! :-)

Original comment by james.st...@gmail.com on 8 Oct 2008 at 3:39

[GoogleCodeExporter]

This patch is for Guice 2.x, right?

Original comment by anthony....@gmail.com on 22 Dec 2008 at 2:03

[GoogleCodeExporter]

Yes

Original comment by james.st...@gmail.com on 22 Dec 2008 at 2:04

[GoogleCodeExporter]

Can I use this to redefine "Singleton" guice anotation as custom 
anotation"MySingleton"?
How can download this patch/fix?

Original comment by jose.ill...@gmail.com on 6 Feb 2009 at 2:32

[GoogleCodeExporter]

This patch only addresses using custom annotations as both a pointcut to inject 
new values into (e.g. to annotate 
fields/properties/methods) and to allow those annotations to be bound to a 
custom ResourceProviderFactory for 
providing their value. e.g. to use @Context from JAX-RS or to provide @Resource 
in JSR-250 / EBJ3 

Its not an attempt to allow custom annotations to replace other Guice 
annotations.

Original comment by james.st...@gmail.com on 6 Feb 2009 at 3:06

[GoogleCodeExporter]

Then, this patch allows "custom injects": Custom annotations to injects values
(generated by CustomProviderFactory) on fields/properties/methods.

It´s true?

Original comment by jose.ill...@gmail.com on 9 Feb 2009 at 6:25

[GoogleCodeExporter]

Thats exactly right Jose. So you can create a Module which defines injection 
points
using whatever annotations you like; be they standards (JSR 250, EJB3, JAX-WS,
JAX-RS, Servlet 3) or your own application specified injection points - then
associate a provider of values to that injection point. This allows the 
provider to
be able to reuse context (such as the field/method name, type or attributes of 
the
annotation) to figure out how to create the values. 

It also opens up Guice to be a possible dependency injection engine within these
various frameworks (JAX-RS / EJB3 / Servlet 3 etc) rather than framework 
developers
having to write their IoC engine. 

I'm sure lots of frameworks would be happy to just reuse Guice as their 
preferred IoC
implementation - rather than forcing their users to scrap JAX-WS / JAX-RS / 
EJB3 /
Servlet 3 and adopt Guice's one true set of annotations - or  drop Guice 
entirely and
just use Spring (which does provide an easy mechanism to write your own 
injection
points).

Original comment by james.st...@gmail.com on 10 Feb 2009 at 10:26

[GoogleCodeExporter]

Frameworks can already do this with Guice source code directly, if they wish. 
I'm not sure I see the benefits of 
cherry-picking our (current, reflection-based) DI internals and ignoring 
everything else.

As for servlets, Guice already injects components quite comprehensively, as of 
Guice Servlet 2.0 (see the wiki on 
Servlets).

Original comment by dha...@gmail.com on 10 Feb 2009 at 2:31

• Added labels: Type-Extension
• Removed labels: Type-Defect

[GoogleCodeExporter]

Dhanji, so are you basically saying 'fork off' :). 

i.e. no way is Guice ever gonna try and be reusable with other frameworks - 
you're
only course of action is to fork the Guice source code?

Original comment by james.st...@gmail.com on 10 Feb 2009 at 3:03