On Oct 7, 2008, at 6:00 PM, Gili wrote:
>
>
> Paul Sandoz wrote:
>>
>> Lets differentiate between the resposibilities such that Guice
>> injects
>> what Guice understands and Jersey injects what Jersey understands
>> according to what is specified by JAX-RS.
>>
>
> I see two problems with this approach.
>
> 1) Some of us want Guice to handle all injection. See
> http://groups.google.com/group/google-guice/browse_thread/thread/649f1a24c62a2bae
>
I think that is a good idea. Not much i can do about that at in the
near term as Jersey is not currently built to depend directly on any
IoC framework :-( and i am not sure if it should, but i am open to
suggestions on this aspect, including basing things on Guice if there
is good interop between Spring and WebBeans and it can support all
requirements without patching, plus Guice 1.0 is about 500k in size,
which makes me pause. I would prefer to avoid implementing and
maintaining n different JAX-RS/Jersey injection implementations for n
different IoC frameworks.
> 2) Even if we wanted to firmly separate Jersey and Guice, where each
> one
> would be responsible for injecting their own classes, there is no
> (simple)
> way to implement it with the current architecture.
>
> Currently, Jersey asks Guice to inject all classes (even Jersey-
> specific
> ones) and if it fails Jersey does the injection itself. This is not
> the same
> as asking Jersey to inject its own classes and Guice to inject its
> own.
> Because there is no firm separation I am unable to throw a fatal
> exception
> if Guice fails to inject a class that it is expected to inject.
>
> For example, if someone annotated a class with Guice scoping rules
> but at
> runtime Guice fails to inject it (because something is wrong with the
> configuration) then it falls back on Jersey's built-in injection and
> ignores
> all the Guice annotations, which is wrong. Users would expect a hard
> failure.
>
I agree, it is not perfect and i would like to improve it. But there
is a reasonable degree of implementation that can be achieved today. I
think the same degree for Spring can be achieved for Guice. The Guice
component provider could look at the package name of the class to be
instantiated and return null for those in the jersey package. Then it
could return hard failures for classes in cannot cannot construct and
inject on. Not perfect, perhaps there could be an option for a 'keep
on truckin' approach that logs warnings and lets Jersey have a go?
i.e. there is a programatic engineering position that can be achieve
that is probably good enough for a reasonable number of cases.
I would like to review what we could do to improve things for Jersey
1.0.1.
Paul.