We tried a lot of things in the JSR-311 EG to make JAX-RS better integrate with Guice (and Spring, and others). Unfortunately for several reasons we failed to reach a satisfactory conclusion. There are several threads on this on both the Guice list as well as the jsr311.dev.java.net list (keywords: scope, lifecycle, guice, factory).
If you can lobby for a more sensible approach to Resource providers, perhaps we can do something in a maintenance release. By contrast JSR-303's ConstraintFactory is a neat approach, very easy to integrate with DI (where incidentally, I used the same arguments to better effect). The best we were able to do in 311 was to prevent defining a full blown proprietary component model like EJB. Dhanji. On Wed, Oct 8, 2008 at 2:41 AM, Gili Tzabari <[EMAIL PROTECTED]> wrote: > > > I totally agree with your post. The current situation is a mess. > I've star-ed the issue, hopefully some form of it will make it into > Guice 2.0. > > Thanks, > Gili > > James Strachan wrote: >> 2008/10/7 Gili <[EMAIL PROTECTED]>: >> >>> Hi, >>> >>> Can someone from the Guice core development team please take a look at >>> http://n2.nabble.com/Using-Guice-with-JAX-RS-tt1127230.html >>> >>> I've integrated Guice into Jersey (the reference implementation for >>> JAX-RS) but the implementation is fragile. If you read that discussion >>> thread you will likely see a lot of potential RFEs for Guice to fix >>> this. >>> >>> One topic I had in mind is the fact that Jersey knows how to inject >>> some classes, Guice knows how to inject others, but they cannot share >>> that information with one another. Ideally I want Guice to inject all >>> the classes it knows and ask Jersey how to inject some type before >>> deciding to throw ConfigurationException. >>> >> >> Ironically, from a different direction (implementing @Resource >> injection from JSR250/EJB3) I kinda hit the same kinda issue today & >> tried implementing a generic hook in Guice to solve these kinds of >> issues. >> >> There's a patch here: >> http://code.google.com/p/google-guice/issues/detail?id=258 >> >> and a thread I just started discussing it here... >> http://groups.google.com/group/google-guice/browse_thread/thread/649f1a24c62a2bae >> >> >> I've hit similar issues in the past using JAX-RS with Spring too BTW; >> you kinda want really one IoC framework to do all the injection, >> including some framework specific injection points (like the @Context >> / @ PathParam values from JAX-RS etc) >> >> >> >>> To be fair, this use-case is rather ugly. It isn't clear what should >>> happen if a class is marked up using Guice annotations but Guice >>> doesn't know how to configure it because it isn't bound in the Module. >>> Jersey would be able to inject it but it will end up ignoring the >>> Guice annotations. I want to avoid misleading the user into thinking >>> Guice took all his annotations into consideration when in fact it did >>> not. >>> >> >> Yeah - I'd prefer Guice to do all the injections, including the >> Jersey/JAX-RS injections too; which shouldn't be too hard to be honest >> if something like the patch for 258 is applied it'd be quite trivial. >> That way Guice does all the injections in a single, consistent way >> rather than adding framework specific hacks etc. >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
