From james.strachan on October 07, 2008 08:27:25

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

From latchkey on October 08, 2008 08:30:20

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

From james.strachan on October 08, 2008 08:39:08

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

From anthony.muller on December 22, 2008 06:03:02

This patch is for Guice 2.x, right?

From james.strachan on December 22, 2008 06:04:35

Yes

From jose.illescas on February 06, 2009 06:32:29

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

From james.strachan on February 06, 2009 07:06:33

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.

From jose.illescas on February 09, 2009 10:25:59

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

It´s true?

From james.strachan on February 10, 2009 02:26:28

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).

From dhanji on February 10, 2009 06:31:43

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).

Labels: -Type-Defect Type-Extension

From james.strachan on February 10, 2009 07:03:10

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?

From limpbizkit on February 10, 2009 09:02:34

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.

From dhanji on February 10, 2009 13:58:14

@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. ;)

From jose.illescas on February 23, 2009 14:57:19

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

From gili.tzabari on February 23, 2009 16:05:49

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.

From stolsvik on February 23, 2009 16:34:04

@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!

From gili.tzabari on February 23, 2009 17:03:06

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.

From stolsvik on February 23, 2009 17:28:20

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.

From gili.tzabari on February 23, 2009 17:49:01

"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.

From stolsvik on February 23, 2009 18:09:51

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.

From gili.tzabari on February 23, 2009 18:22:26

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.

From stolsvik on February 23, 2009 18:38:11

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!

From limpbizkit on February 24, 2009 00:15:33

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.

From james.strachan on February 24, 2009 02:01:03

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 :)

From gili.tzabari on February 24, 2009 05:28:14

James,

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

From stolsvik on February 24, 2009 06:00:26

@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.

From limpbizkit on February 24, 2009 09:49:19

@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".

From gili.tzabari on February 24, 2009 10:13:18

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).

From jose.illescas on February 24, 2009 14:09:27

@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"

From bslesinsky on February 24, 2009 19:04:29

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).

From james.strachan on February 25, 2009 01:15:17

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
( https://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.

From bileblog on February 25, 2009 05:02:13

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.

From limpbizkit on February 25, 2009 09:11:15

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.

Labels: -Priority-Medium Priority-High

From james.strachan on February 25, 2009 10:06:19

Awesome! :) Many thanks!

From bileblog on February 25, 2009 15:37:16

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.

From dhanji on February 25, 2009 16:48:21

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.

From mark.renouf on February 25, 2009 18:01:30

@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.

From crazyboblee on February 25, 2009 22:24:05

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. :-)

From michael.neale on February 26, 2009 18:35:29

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

From jose.illescas on February 27, 2009 03:58:03

@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

From james.strachan on April 03, 2009 02:47:33

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

e.g. using the GuiceyFruit library ( https://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: https://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit- core/src/main/java/org/guiceyfruit/jsr250/Jsr250Module.java

From james.strachan on April 03, 2009 02:52:43

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 https://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 https://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit- core/src/main/java/org/guiceyfruit/support/GuiceyFruitModule.java

From limpbizkit on April 03, 2009 17:47:01

James, thank you.

Status: Fixed

From christian.bourque on April 06, 2009 14:50:51

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

Because the last snapshot is dated October 22, 2008!

Thanks

From james.strachan on April 06, 2009 15:47:26

@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.

From christian.bourque on April 07, 2009 11:18:21

@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!

From james.strachan on April 14, 2009 03:55:00

@christian the 2.0-beta-6 release of GuiceyFruit is now out btw! https://code.google.com/p/guiceyfruit/wiki/Download

From jose.illescas on May 06, 2009 06:50:37

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

Thank you