[Patch] custom annotation based injection points

[gissuebot]

From james.strachan on October 07, 2008 11:13:11

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... https://code.google.com/p/google-guice/issues/detail?id=62 https://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

Attachment: gist    _custom_annotation_injections.patch_

Original issue: http://code.google.com/p/google-guice/issues/detail?id=258

[gissuebot]

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

[gissuebot]

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

[gissuebot]

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

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

[gissuebot]

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

This patch is for Guice 2.x, right?

[gissuebot]

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

Yes

[gissuebot]

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?

[gissuebot]

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.

[gissuebot]

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?

[gissuebot]

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

[gissuebot]

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

[gissuebot]

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?

[gissuebot]

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.

[gissuebot]

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

[gissuebot]

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

[gissuebot]

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.

[gissuebot]

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!

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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!

[gissuebot]

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.

[gissuebot]

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

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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

[gissuebot]

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

[gissuebot]

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"

[gissuebot]

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

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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

[gissuebot]

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

Awesome! :) Many thanks!

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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.

[gissuebot]

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

[gissuebot]

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

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

[gissuebot]

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

[gissuebot]

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

[gissuebot]

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

[gissuebot]

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

James, thank you.

Status: Fixed

[gissuebot]

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

[gissuebot]

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.

[gissuebot]

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!

[gissuebot]

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

[gissuebot]

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

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

Thank you