[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

[GoogleCodeExporter]

James, your work is fantastic. Keep it up, and I'm intending on taking it all 
in for consideration as soon as we 
push v2 out the door.

With respect to supporting custom annotations, my complaint is that it 
introduces more indirection to Guice, 
without adding more value. Tools like IDEs etc. can use our simple static 
methods on InjectionPoint.class to 
lookup the injection points for a given class. Should we introduce 
InjectionPoint Matchers, it's no longer 
possible to know the injection points for a class statically - you'll need a 
Module to figure them out. I don't 
think this is a net win for our users.

I believe a lot of the motivation for custom annotations is people's distaste 
for importing 'com.google' 
packages into their core classes. But the same people happily import 'java.' 
packages everywhere. I think this 
is a bit irrational, because Google loves you way more than Sun or the JCP does.

Original comment by limpbizkit on 10 Feb 2009 at 5:02

[GoogleCodeExporter]

@james.strachan

What Jesse said =)

There are loads of implications to supporting any annotation or no modules, and 
we want to provide the best 
experience for everyone, which I think the current design does very nicely.

...Also I think Provider methods make it really easy to support and reuse other 
frameworks. And the new 
Servlet module makes it easy to integrate web frameworks like jersey. ;)

Original comment by dha...@gmail.com on 10 Feb 2009 at 9:58

[GoogleCodeExporter]

Limpbizkit, I hate APOJOs (Annotated POJOs) and Anotations of any owner: 
'java(x).',
'com.google', 'org.hibernate', ...

I only likes MY custom anotations (@MyTransactional, @MySecure, @MySingleton,
@MyInject) everywhere

Original comment by jose.ill...@gmail.com on 23 Feb 2009 at 10:57

[GoogleCodeExporter]

I highly dislike Jose's request. I think the main point of this RFE is that we 
should
be able to integrate with existing annotations used by other frameworks. The 
fact
that this also allows one to implement Jose's request is a side-effect but (my 2
cents) we shouldn't go out of our way to allow individual users to define their 
own
annotations just for the sake of not having Guice's package name show up in 
their
imports. It's a complete waste of our time.

So +1 for James' idea and -1 for Jose. Sorry.

Original comment by gili.tza...@gmail.com on 24 Feb 2009 at 12:05

[GoogleCodeExporter]

@Gili: What is it about Jose's request you "dislike"? Seems like you'd want to 
go out 
of your way to NOT allow individual users to define their own annotations?!

@limpbizkit: Imagining that your comment about "com.google" being as good a 
package 
name as "java" wasn't meant as a joke, I find the thought disturbing and silly. 
This 
particular for such central pieces of technology that IoC has become. The time 
has 
probably come where one should start striving towards standardization of the 
IoC 
ideas and obviously also the annotations involved - and such standardization 
should 
hopefully not be with google as part of the package name. Java shouldn't be an 
advertising board!

Original comment by stolsvik on 24 Feb 2009 at 12:34

[GoogleCodeExporter]

Stolsvik,

The complaint about having "foreign" package names in your import list is what 
I find
silly about James and your comments. Java isn't a "designed by a committee" 
language.
Many "standards" are de-facto standards that have eventually been folded into 
the
platform. Even C++ development requires one to #include many non-standard 
namespaces
for 3rd-party libraries.

Who cares what the package name is? The vast majority of Java libraries out 
there are
*not* by Sun. Nor should they be. Again, I find this whole argument very silly. 
The
package name is not an advertisment. According to JLS section 7.7 one is 
encourages
to take the company domain name (google.com in this case) and reverse it to 
form the
package name. Hence, "com.google". This is no different from sun.com using 
"com.sun".

I don't want to come off as an ass, but this entire argument is highly 
subjective. I
can't say that you are wrong, just that I personally disagree with your view 
for the
reasons I outlined above.

Original comment by gili.tza...@gmail.com on 24 Feb 2009 at 1:03

[GoogleCodeExporter]

Definitely highly subjective, I agree. What about this: You'd then be happy 
with 
com.ibm.core.String, com.apple.io.Reader, com.bea.net.URL, com.microsoft.URI, 
com.sun.URI, com.oracle.Connection, com.mysql.Connection, com.jboss.Math, 
com.suse.Remote and so on? That would not annoy you the least?

I think there should be a java core (which should have the java package name). 
Innovation often happens outside the standard, but that shouldn't discourage 
assimilation of the good stuff into the standard. The IoC idea, and the 
refinement of 
the idea using annotations, are such good stuff. The point of the core is to 
make 
interoperability easier. Now we have a situation where several sets of such 
annotations exists. Some steps towards solving the problem would be to make 
Guice 
handle other annotations.

What is somewhat absurd here, is that there apparently already exists a patch 
that 
would make a diverse bunch of people happy about having other options when it 
comes 
to annotations, for a diverse set of reasons. But this patch won't even, it 
seems, be 
looked into. What is the rationale behind this stubbornness?

Limpbizkit says "[custom annotations] introduces more indirection to Guice, 
without adding more value". The idea that this doesn't add value is enormously 
subjective, IMHO.

Original comment by stolsvik on 24 Feb 2009 at 1:28

[GoogleCodeExporter]

"You'd then be happy with [...]"?

String and URL are bad examples in that they are concrete classes but I get your
point. To answer your question, I would be happy with com.ibm.ArrayList that
implements java.util.List. I would choose to use java.util.List all over my 
code (to
remain portable across implementations) but the fact that com.ibm.ArrayList 
shows up
in my import statement is just fine.

Furthermore, nothing prevents Guice from implementing standard interfaces in the
future if some official JSR is published. The fact of the matter is that no such
standard exists today so this discussion is moot.

Look at what happened to Hibernate once JPA came out. You can still use the old
Hibernate classes or the new JPA ones. You can even use the two together, they 
aren't
mutually exclusive. Another example, Jersey as an implementation of JAX-RS. 
When you
use Jersey you end up with both JAX-RS and Jersey import statements. There is no
contradiction there. JAX-RS publishes interfaces. Jersey publishes 
implementation
classes.

Original comment by gili.tza...@gmail.com on 24 Feb 2009 at 1:49

[GoogleCodeExporter]

Regarding java.util.List vs. com.ibm.ArrayList: I agree, and I think that 
@Inject in 
this regard definitely is an interface.

Regarding "no such standard exists today" - read top post.

Regarding Hibernate vs. JPA etc: One may argue that one is there today, and 
that 
Guice would make more people happy if it supported this seemingly simple 
customization option. (Have you read Joel's piece about how Excel won when it 
implemented /export/ filters? Maybe something like that would happen here too - 
people would feel safer when they COULD get out of google's claws if they 
wanted)

IMO, there is no argument about whether Guice is "intrusive". It is: One have 
to 
annotate the code, specifically importing guice/google-specifics. Spring isn't: 
One 
use a completely external configuration. This is a bit sad.

Annotating with standard annotations, or failing that, with project-specific 
annotations, would be nearly the same as no external dependencies. If several 
injection containers implemented the standard annotations, or/and such a 
pluggable 
annotation processing, one would again be free in that one could change the 
container: Either by just changing it (if one used standards), or by doing the 
container-specific customization to process the project-specific annotations. 
There 
is value here - stating otherwise undermines all those success stories of how 
one 
changed from Spring to Guice in a matter of hours. There is one hurdle left: 
The 
semantics of the IoC annotations - but at least for simple cases, which most 
probably 
is the majority, this is probably not very hard.

Original comment by stolsvik on 24 Feb 2009 at 2:09

[GoogleCodeExporter]

I was under the impression that @Resource and other standard annotations do not 
cover
the same (or all) functionality exposed by Guice or Spring. Speaking of which, 
if
there *is* a standard why doesn't Spring annotations use it either? If we're 
going to
compare apples to apples then we should be discussing Spring annotations vs 
Guice
annotations (external configuration files fall outside this discussion). As far 
as I
know both use proprietary annotations.

Original comment by gili.tza...@gmail.com on 24 Feb 2009 at 2:22

[GoogleCodeExporter]

http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-
in-2-
ioc-annotations

http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-
resource-annotation

The semantics are slightly off, but these things are converging. Spring's 
annotation 
driven IoC processing along with its JavaConfig project makes Guice not the 
only kid 
on the block with "new style" IoCing. I think Guice should open up wide!

Original comment by stolsvik on 24 Feb 2009 at 2:38

[GoogleCodeExporter]

stolsvik, please embrace the fact that Java uses domain names in imports. 
You've also criticized the package 
name in Glazed Lists, and it's getting extremely tiresome. Your application's 
users would prefer for you to focus 
on features and bugs.

Original comment by limpbizkit on 24 Feb 2009 at 8:15

[GoogleCodeExporter]

Gili - its a shame you think my comments are silly though I'm not exactly sure 
what
it was you were referring to. 

FWIW my motivation for this patch was not because I dislike using com.google.* 
- its
that I like being able to support *existing* popular standards like JSR 250 / 
EJB3
annotations (e.g. @Resource / @PreDestroy / @PostCommit) which are very widely 
used.
They are the nearest thing we have to IoC standards right now. (@Resource is 
kinda a
standard version of guice's proprietary @Name). Most popular standards define 
some
kind of IoC annotations these days (JSR 250, EJB3, JPA, JAX-RS, JAX-WS, 
WebBeans etc). 

If you work solely inside your corporate firewall and don't have to share code 
with
customers you probably don't care about standards - but many of us outside the
googleplex do I'm afraid and for something as pervasive at so many layers as IoC
standards are a good thing IMHO.

FWIW many other IoC containers have supported these annotations for *years* 
(e.g.
Spring) as well as letting anyone, easily add any kind of annotation processor 
to
encourage innovation.

For some reason supporting standards that people actually use seems kinda 
against the
insular Not Invented Here Google way. Looks like its Spring and JavaConfig for 
me
going forward (which is pretty good too - and fully supports JSR 250 & EJB3 
already
and is super easy to extend to support custom annotation injections). 

Its a shame as Guice was really close to being a contender as a really popular 
IoC
framework outside of Google. Fingers crossed for Guice 3 in, what, 2012? Though 
I've
a feeling it'll be game over by then and folks will just use Spring JavaConfig
(assuming Java is still popular by then :)

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

[GoogleCodeExporter]

James,

I'm sorry if I misunderstood your comments. I am all in favor of reusing 
standard
annotations (such as @Resource) if possible.

Original comment by gili.tza...@gmail.com on 24 Feb 2009 at 1:28

[GoogleCodeExporter]

@limpbizkit: Glazed Lists uses a coding, java and computers-unrelated domain 
name of 
a weapons-touting company. I have never shown any intent on /not/ having a 
domain-
name in GlazedLists, but why not use [com|org|net].glazedlists, all of which 
actually 
are available, instead of a BLOODY GUNS'n'AMMO COMPANY??

You are //completely// derailing the discussion, and of course you know it.

I do not, in any way, want you to take away com.google from the system aspects 
of 
Guice (that is actually slightly cool!), but I want you to make it possible for 
the 
annotations, and hence my and others' code, to not be bound to Google's 
specific 
annotations. This I have been clear about in this and other bugs' discussion 
all the 
time.

So DO NOT put completely baseless meanings into my mouth.

I cannot comprehend why it is problematic for you Googlers to understand that 
not 
everyone is happy with having all their code, and all others' code, be "bound 
to 
Google" via Guice's annotations. I actually don't mind very much that my own 
code has 
these annotations, but I find it a huge problem that any future 
"IoC-compatible" code 
that I take into my project will have to be Guice specific. (and yes, one have 
Providers, but that's rather beside the point in this discussion)

Spring does not force you to such measures, in any way, and never has - that 
was its 
main idea! Guice probably got a huge migration from Spring, due to the 
innovative 
thoughts by Bob embedded in the system. But if you don't consider your users' 
whishes 
nor code submissions, while Spring copies all the innovation back again (only, 
as 
always, not trying to do a lock-in on you), I know you will have a migration 
back.

From a bit more abstract view: One big point of the entire IoC stuff was that 
one 
could write "POJOs", without dependencies on any container-specifics, and use 
an 
external tool to stitch these together. This made the code completely container-
unaware, and all of a sudden one could just code, and pick the container 
afterwards, 
or at least not be bound to a specific container (or just wire them yourself, 
as in 
testing). Guice showed that using annotations, and using java to do the wiring, 
gave 
quite a bit of type safety and refactorability, both missing very much from 
Spring's 
XML hell. But this came at price - now your supposedly POJOs are again 
implementing a 
/specific/ container's "interface": The Google annotations. This will probably 
hurt 
both the emergence of open source, or otherwise free, generically IoC-annotated 
code, 
and possibly the adoption of Guice once more and more developers figure these 
facts 
out themselves.

Original comment by stolsvik on 24 Feb 2009 at 2:00

[GoogleCodeExporter]

@james.strachan please don't leave us! It's easy to use third-party 
annotations, or XML, or whatever you like, 
on top of Guice. For a cute example, see the XML code Bob recently checked into 
the core source tree. 

Guiceyfruit is awesome and I hope you continue it. And I'm intending to review 
your patch as soon as we push 
Guice 2 out-the-door. Naturally, that's taken much longer than I'd anticipated, 
and the delay is making me 
quite sad. We want to make you happy, you're one of the best contributors in 
our small community.

I'm fairly skeptical of arguments that say "import javax.*" is good, but 
"import com.*" is bad, mostly because 
there's a lot of extremely good code that starts with "com" and also a lot of 
extremely bad code that starts 
with "javax".

Original comment by limpbizkit on 24 Feb 2009 at 5:49

[GoogleCodeExporter]

Jesse,

I think we've all misunderstood James' point. He doesn't object to the package 
names
but rather to the difficulty of migrating across different IoC implementations. 
If
the standard @Resource annotation is "good enough" to cover the Guice 
implementation
why *shouldn't* we be using it instead of defining our own? That is, Guice 
should use
existing annotations/interfaces as much as possible instead of generating our 
own
(again, when it is reasonable).

Original comment by gili.tza...@gmail.com on 24 Feb 2009 at 6:13

[GoogleCodeExporter]

@limpbizkit this is not sun(java.*) vs google(com.google.*) war
@gili you really misunderstood me
@james GREAT work

I loves Guice Interceptor, based on customs annotations allows me define:

   @Transactional: add transactions to any method
   @Secure({Role1, Role2}): adding authorization based on role list

But, If I like to change quickly between guice/spring/other? (without lost 
amounts of
time) custom annotations is the only exit (IMO)

note: custom = any

   Nobody can say: "I use *** framework in the future"

Original comment by jose.ill...@gmail.com on 24 Feb 2009 at 10:09

[GoogleCodeExporter]

It seems like there are two issues here:

1) standardizing on common names for things (e.g. naming injection points)
2) the code that implements this standard.

Guice is both a (de-facto) standard and an implementation. If you're not using
Guice's annotations, you're not following the Guice standard, but rather some 
other
standard. It seems perfectly reasonable for someone to write code to some other
standard and even to embed the Guice core into a dependency engine for some 
other
standard, but we don't want to confuse people about what the Guice standard 
actually
is. It should be obvious that you're doing something non-standard (from Guice's 
point
of view).

Original comment by bslesinsky on 25 Feb 2009 at 3:04

[GoogleCodeExporter]

To avoid lots of philosophical discussions (what is a standard etc) let me try 
to be
100% clear exactly what my use case is. I get the impression there's lots of 
folks
talking past each other not really hearing each other - so here's my last 
attempt at
being crystal clear.

I work on lots of application code which is used by lots of different teams in
different companies. This code is usually used by some IoC framework decided by 
the
user of the code (not the author of the code). Today the most common IoC 
framework I
see in use is Spring (its used in > 90% of teams I work with). Guice may or may 
not
be the best IoC container (its always gonna be subjective) - however I am not 
in the
position to dictate to all the users of my code what IoC container to use - nor 
can I
force them to refactor their code to switch IoC containers. If you're in the
googleplex this is never an issue - you can just refactor all the code to use
whatever you need. Outside of the googleplex the world is not so simple and 
sometimes
ideal technical solutions have to take a back seat to pragmatic decisions. 

So my show stopper issue with ever adopting & recommending Guice is to be able 
to use
IoC framework agnostic annotations for lifecycle & injection (JSR 250/EJB3 for
starters, @Resource, @PostConstruct, @PreDestroy - you could throw
Spring/WebBeans/JAX-RS/JAXWs in there too really but JSR250/EJB3 is the tip of 
this
massive iceberg). i.e. so that my application code can be used by Spring or 
Guice IoC
containers without having to double-annotate everything (using JSR 250 and Guice
annotations) or using JSR 250 annotations then forcing producer methods for 
every
class I write to be written by users using Guice. 

It might not be the ideal solution - if you could dictate Guice everywhere on a
project then using the Guice specific annotations might be better - but given 
the
pragmatic real world I work in - its a fundamental requirement. These IoC 
container
agnostic annotations have been around for years, supported by all the IoC 
frameworks
I see users & customers already using (e.g. Spring/JBoss/GlassFish and even J2EE
servers). Its really a no brainer supporting them. Sure the Guice annotations 
might
be better - if you can assume that all your user base will only ever be using 
Guice
as the IoC container - but thats not really my point here. I'm 100% happy for 
folks
to use guice specific annotations when they can (when they own the application 
code
and choose the IoC container).

Right now the only IoC container I'm aware of which refuses to allow such a 
heretical
idea as supporting the standard set of IoC annotations in widespread use today 
is
Guice. Despite providing a relatively simple patch to fix this show stopper 4 
months
ago - I'm told I must wait for Guice 2 (its been 2 years in the making so far - 
no
idea when it might turn up) and then after that for Guice 3 (in what, 2-4 years
time?) when this show stopper issue *might* be addressed?

So my choice today is - forget all about Guice, carry on using Spring 
JavaConfig (no
XML, kinda guicy-ish, pretty good - works with any annotations the developer 
(rather
than the guice committer) chooses to use and comes out of the box with JSR 
250/EJB3
support baked in) and carry on working - or sit on my hands and wait 2-4 years 
for
Guice 3 and maybe, that might be usable. I think you can see why Spring 
JavaConfig is
my IoC container of choice until Guice 3 turns up. 

Hey good luck - Guice is a good piece of work and I wish it well. I hope at some
point something vaguely like my patches
(http://code.google.com/p/guiceyfruit/wiki/GuicePatches) do get applied so at 
some
point I could consider Guice for a project - but I'm not holding my breath and I
suspect quite alot of other potential guice users won't be either.

Original comment by james.st...@gmail.com on 25 Feb 2009 at 9:15

[GoogleCodeExporter]

I agree 100% with James' comments, but have far far less patience than he does. 
I'v jumped off the guice ship months ago, and whenever asked, I recommend that 
people avoid it.

The reasoning is exactly the same as James'. The constant refusal to add 
support for annotations that are in use by everyone, require no new knowledge, 
that have become commonplace 
everywhere else is perplexing, to say the least. The argument that javax.* is 
bad code and com.* is good code is....and I'm putting this in the most polite 
way I know...idiotic, moronic, 
and ignorant. Have you any idea how much bad com.* code is out there? However, 
I won't get sidetracked by addressed such a silly claim, and will stick to the 
point at hand.

It's perplexing to me that after being assured a year or two ago that Guice 
will provide infrastructure to support these common annotations, the solution 
now has gone to 'sorry, we don't 
trust them'. Even the Guice BOF at JavaOne last year made comforting noises 
about the ability to support custom annotations via listeners. In fact, I'm 
fairly sure that I've filed an issue 
more or less after the first first Guice public preview stating the need for 
these annotations.

It's become abundantly clear that Guice's priorities are much the same as 
Google's priorities when it comes to open source that it uses in house, Google 
first, and if that happens to 
benefit the community incidentally, then that's great, if not, then that's 
great too.

You keep wondering why people care, and the answer is simple. It's less to 
learn, it lowers the barrier to entry, and saves you a few extra seconds of 
thinking 'now how do I do the thing 
I've been doing for months elsewhere...' I work with a lot of developers, and 
now they're all comfortable with things like @PreConstruct @Resource, 
@TranasactionAttribute, and so on. 
There's no sane reason why they should now have to learn another set of 
annotations that perform the exact same role if they ever want to use Guice, or 
even worse, being told that 
'sorry, that model is not even possible, you need to think differently and 
pretend like Guice has it all figured out'. It reminds me of when the 
picocontainer guys refused to do setter 
injection, claiming constructor injection is the only way to go. Look at where 
pico is now.

See, the community is perfectly happy for you to maintain your elitist selfish 
attitude to the codebase, and your refusal to add features that don't 
personally benefit you. It's the Guice 
way, and that's totally fine. What's infinitely more frustrating is your 
refusal to add extensions to enable other people to do what they need to do. 
Fine, don't add support for standard 
annotations if they insult your purist insular view of the world, but give us 
annotation listeners or whatever other infrastructure so that the rest of us 
who work in the real world can deal 
with such dirty concepts as javax.* code.

Original comment by bileb...@gmail.com on 25 Feb 2009 at 1:02

[GoogleCodeExporter]

I'm convinced.

Sincere apologies for being ivory-tower with my previous arguments. I've 
certainly underestimated how 
urgently this patch is desired. That's my own fault.

I didn't fully understand the motivation behind this patch. I foolishly assumed 
people wanted to use 
@Resource because it was more pure to use a javax.* API than a com.google API. 
Of course, the real issue is 
that you've already got thousands of lines of code that already use @Resource 
etc., and you'd like to use that 
code with Guice. And I didn't realize how painful/impossible/unpleasant it is 
be for you all to add @Inject to 
existing code.

Also, when I said "after 2.0" what I really meant was "immediately after 2.0". 
Adding new functionality like this 
can destabilize, and I wanted to first release what we already have. 
Unfortunately, I was originally intending to 
release 2.0 six months ago, but the release has been delayed. I'm currently 
polishing up the docs so we can 
push it out ASAP.

Hani, we've done a lot of work to make Guice work better for the community 
outside of Google, and it makes 
me sad to see you say otherwise. In particular, OSGi and Maven support are 
exclusively for the benefit of the 
community, and they've both taken quite a bit of work. 

Original comment by limpbizkit on 25 Feb 2009 at 5:11

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Awesome! :) Many thanks!

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

[GoogleCodeExporter]

Well, that's a relief!

I still though am grumpy about the lack of 2.0, it's just so much stuff 
promised, but very little delivered (that I 
can see).

I do hope you get 2.0 out before the boat has passed though, and will 
definitely revisit once some of these 
features make it in.

Original comment by bileb...@gmail.com on 25 Feb 2009 at 11:37

[GoogleCodeExporter]

hooray, everyone is happy again.

Also, let's not forget servlet support, which is for the community as much as 
it is for us internally. 

I think it's worth appreciating Jesse a little as he's worked extremely hard to 
make this happen. It may appear 
that there's been no commit activity on Guice for weeks, but what you don't see 
is Jesse working diligently to get 
Guice tested against all of our internal projects, which are numerous and vast 
to say the least.

Original comment by dha...@gmail.com on 26 Feb 2009 at 12:48

[GoogleCodeExporter]

@bileblog Guice 2 has been stable and available for quite some time, available 
from
SVN. We took a leap of faith and pulled down a snapshot of it and use that
internally. I really look forward to using an official 2.0 though.

Kudos to everyone, google, contributors, and everyone here providing input. I'm 
glad
to see people communicating and listening.

Original comment by mark.ren...@gmail.com on 26 Feb 2009 at 2:01

[GoogleCodeExporter]

James, you rock. We really appreciate the contributions. We won't let you 
down--we'll
make sure construction listeners (or something comparable) makes it into Guice 2
which is coming *very soon* thanks to Jesse's tireless efforts. I know how much 
of a
pain maintaining external patches can be.

My single biggest regret about Guice 1 is that I didn't rename the package to 
"guice"
when I open sourced it. Too late now though.

I could go on about the tragedy in "Java standard" becoming synonymous with 
"JCP",
but I won't. :-)

Original comment by crazybob...@gmail.com on 26 Feb 2009 at 6:24

[GoogleCodeExporter]

Smile on your brother everybody get together gotta love one another right now. 

Original comment by michael....@gmail.com on 27 Feb 2009 at 2:35

[GoogleCodeExporter]

@james: one more thing...

It's necesary a Module "binding"?
for example:
   binder.<bindInjectorProvider>(@Resource, ResourceProviderFactory.class);

note: this allows me configure providers on my Module

Original comment by jose.ill...@gmail.com on 27 Feb 2009 at 11:58

[GoogleCodeExporter]

@jose: Great point! I've gone ahead and implemented that now BTW.

e.g. using the GuiceyFruit library (http://code.google.com/p/guiceyfruit/)

using the current trunk of Guice you can do things like this...

    bindAnnotationInjector(Resource.class, ResourceMemberProvider.class);

For more detail see the JSR 250 module:
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-
core/src/main/java/org/guiceyfruit/jsr250/Jsr250Module.java

Original comment by james.st...@gmail.com on 3 Apr 2009 at 9:47

[GoogleCodeExporter]

BTW we can mark this issue closed now IMHO!

There's everything you need in Guice trunk now to implement any kind of custom 
injection strategy.

e.g. here's an example of it in use
http://tinyurl.com/ch8u4q
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-
core/src/main/java/org/guiceyfruit/jsr250/Jsr250Module.java

and here's how the code works (just a few simple helper methods on standard 
Guice)
http://tinyurl.com/cp9q9g
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-
core/src/main/java/org/guiceyfruit/support/GuiceyFruitModule.java

Original comment by james.st...@gmail.com on 3 Apr 2009 at 9:52

[GoogleCodeExporter]

James, thank you.

Original comment by limpbizkit on 4 Apr 2009 at 12:47

• Changed state: Fixed

[GoogleCodeExporter]

Will there be a 2.0-beta-6 release soon (including these patches)?

Because the last snapshot is dated October 22, 2008!

Thanks

Original comment by christia...@gmail.com on 6 Apr 2009 at 9:50

[GoogleCodeExporter]

@christian: are you talking about guice or guiceyfruit (only the last 
guiceyfruit
release was 2.0-beta-5 which has the above patches included which made me think 
you
were talking about that). 

There should be a 2.0-beta-6 release of guiceyfruit cut this week with Spring
annotations support too... I can't speak for the guice folks though and their 
release
cycle.

Original comment by james.st...@gmail.com on 6 Apr 2009 at 10:47

[GoogleCodeExporter]

@james: I was talking about GuiceyFruit...

I was wondering because it seems there's no nightly builds available, the 
snapshot
repo is outdated...

Thanks James!

Original comment by christia...@gmail.com on 7 Apr 2009 at 6:18

[GoogleCodeExporter]

@christian the 2.0-beta-6 release of GuiceyFruit is now out btw! 

http://code.google.com/p/guiceyfruit/wiki/Download

Original comment by james.st...@gmail.com on 14 Apr 2009 at 10:55

[GoogleCodeExporter]

@james: GREAT PATCH!! 
@limpbizkit: When add this patch on Guice?

Thank you

Original comment by jose.ill...@gmail.com on 6 May 2009 at 1:50