On Apr 30, 2010, at 4:07 PM, James Strachan wrote:
> I started tinkering with some Guice IoC in a Scalate Jog project...
> http://scalate.fusesource.org/documentation/jog.html
>
> and was quite suprised to not have a resource injected when using
> Guice's @Inject. Turns out I think that the code only attempts to use
> Guice to inject if it can see an @Inject annotation on a constructor -
> or the resource is bound with the module.
>
Yes.
> I just wondered why this was done?
It simply did not occur to me to check for other uses of @Inject. I
was just looking for an explicit marker to ensure Guice support would
not gobble up all classes to be instantiated by Guice (see later).
> I figured at least check for
> method/field annotations too? I've raised an issue to track it...
> https://jersey.dev.java.net/issues/show_bug.cgi?id=520
>
> Maybe we should just change the
> GuiceComponentProviderFactory.isImplicitGuiceComponent method to
> check for @Inject on any field or method too?
>
Yes, i think we can modify to do more checking. Basically if it quacks
like a Guice component but is not bound let Guice instantiate it.
> Would it be too bad to just assume Guice is gonna create an instance I
> wonder?
The problem is that thorny issue of constructor injection:
public class MyClass {
public MyClass(@PathParam("p") String p) {
...
}
}
thus we don't want Guice to instantiate stuff like the above.
Perhaps we can try these rules:
1) check if there is a constructor annotated with @Inject, if not
2) check for fields/methods annotated with @Inject.
and let Guice throw up errors if construction fails?
Do you know if it is possible to pass an instance to Guice to be
injected on? If so we might be able to support Jersey constructing +
injecting, then Guice injecting.
I *really* do want to sort out these DI issue for Jersey 2.x. Namely
ripping out the guts of Jersey re-using a proper DI framework. Re:
discussons on using Weld. As i have said before I would really like to
use a fork of Guice + modifications (with appropriate integration to
CDI and Spring). But i sort of feel stuck, forking Guice obviously has
issues but as long as it is backwards compatible with Guice then maybe
developers will not mind?
BTW on request i modified the Guice dependency to point the maven
central repo rather than GuiceyFruit but still give the latter a plug
in the dependency docs.
https://jersey.dev.java.net/nonav/documentation/1.2-SNAPSHOT/user-guide.html
#d4e1669
Paul.
> e.g. in case we also use JSR 303 @Inject too or other custom
> injection annotations like @Resource etc?
>
> I just wondered if folks implemented it this way for a specific reason
> - if not I was going to experiment making the code try to use Guice in
> more than this very restrictive situation (constructor injection
> only)?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>