Worked like a charm :) Thank you!Gili On 30/03/2011 10:59 AM, Brian R. Jackson wrote:
If you define the Guice and Jersey dependencies explicitly in your project, Maven will resolve the version conflict in your dependency tree without a need for an explicit exclusion. If you are getting them transitively its a little trickier and you need to understand which version is closest to the root of your dependency tree. I find "mvn dependency:resolve" and "mvn dependency:tree" very helpful for exploring my project's dependency tree. For example, I have to following dependencies in a current working project of mine: .... <!-- Guice support --> <dependency> <groupId>com.google.inject</groupId> <artifactId>guice</artifactId> <version>3.0</version> </dependency> <dependency> <groupId>com.google.inject.extensions</groupId> <artifactId>guice-servlet</artifactId> <version>3.0</version> </dependency> <!-- Jersey 1.5 transitively depends on Guice 2.0, but the above dependencies are declared closer to my dependency tree root so 3.0 'wins'. --> <dependency> <groupId>com.sun.jersey.contribs</groupId> <artifactId>jersey-guice</artifactId> <version>1.5</version> </dependency> On Mar 30, 10:13 am, cowwoc<[email protected]> wrote:Ah! I'll give that a try. Thank you, Gili On 30/03/2011 10:01 AM, Colin Decker wrote:You can add a dependency on Guice 3.0 in your project and add an exclusion to the jersey-guice dependency that excludes its dependency on Guice. -- Colin On Wed, Mar 30, 2011 at 9:55 AM, cowwoc<[email protected] <mailto:[email protected]>> wrote: I'm using Maven. I don't think I can force jersey-guice (my project's dependency) to change its own dependency without recompiling it. On the other hand, perhaps Maven handle version mixing automagically...? Gili On 30/03/2011 9:52 AM, Sam Berlin wrote:If you're in control of the ultimate jars used on the classpath, you _should_ be able to use just Guice 3.0 without any problems (unless Jersey happens to use some arcane/odd/internal bits of Guice). If you use both 3.0& 2.0 on the classpath, you may have some funkiness. If you're unable to do that... try convince the Jersey folks to update to Guice 3. sam On Wed, Mar 30, 2011 at 9:50 AM, cowwoc<[email protected] <mailto:[email protected]>> wrote: jersey-guice depends on Guice 2.0. What will happen if my main codebase uses Guice 3.0 and jersey-guice uses 2.0? Won't I run into funky conflicts? Gili On 30/03/2011 8:51 AM, Sam Berlin wrote:Give guice 3.0 and FactoryModuleBuilder a shot. It's a rewritten and better way of dealing with assisted inject. sam On Mar 30, 2011 8:30 AM, "cowwoc"<[email protected] <mailto:[email protected]>> wrote: > It looks like guice-assistedinject attempts to resolve the UriInfo > binding when FactoryProvider.newFactory() is invoked, but Jersey only > defines the UriInfo binding at a later part of the Module. > I was under the impression that guice bindings are only supposed to > get resolved at Injector-creation time. Is there a way to defer > AssistedInject's type resolution to that time? > Thanks, > Gili > On Mar 29, 3:44 pm, cowwoc<[email protected] <mailto:[email protected]>> wrote: >> Hi, >> Using Guice 2.0 I am able to @Inject top-level Jersey components whose >> constructor refer to UriInfo, however when I try using AssistedInject >> for constructors referring to UriInfo I get this error: >> No implementation for javax.ws.rs.core.UriInfo was bound. >> JerseyServletModule defines the following bindings: >> @Provides >> @RequestScoped >> public UriInfo uriInfo(WebApplication wa) { >> return wa.getThreadLocalHttpContext().getUriInfo(); >> } >> @Provides >> public WebApplication webApp(GuiceContainer guiceContainer) { >> return guiceContainer.getWebApplication(); >> } >> Why would the two injection types differ? Any ideas? >> Thanks, >> Gili > -- > 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] <mailto:[email protected]>. > To unsubscribe from this group, send email to [email protected] <mailto:google-guice%[email protected]>. > For more options, visit this group at http://groups.google.com/group/google-guice?hl=en. -- 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] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto:[email protected]>. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.-- 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] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto:google-guice%[email protected]>. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.-- 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] <mailto:[email protected]>. To unsubscribe from this group, send email to [email protected] <mailto:google-guice%[email protected]>. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en. -- 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.
-- 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.
