Yes, I just posted a detailed explanation of why this works for Spring
and fails for Guice. Please note, however, that it could still fail
under Spring in the following case:
@Path FirstResource
{}
@Path
class SecondResource
{
private FirstResource first;
private UriInfo uriInfo;
public someMethod()
{
uriInfo.path(first.getClass()).build(); // wrong class will be used
}
}
Even Spring will need to implement getInjectableClass() in this case,
but for obvious reasons this method is a lot more important for Guice
than for Spring.
Gili
Paul Sandoz (via Nabble) wrote:
> Hi Gili,
>
> Note that for Spring it all works OK as is.
>
> The reason: the Class that is passed to the
> IoCComponentProviderFactory.getComponentProvider is the class that is
> reflected on and not the class of the object returned by the
> ComponentProvider.getInstance method.
>
> So i would assume it would be OK for Guice.
>
> We need to ascertain for the instance returned by Guice whether it
> can be used to say do this:
>
> Field f = ... // obtain a field from the (unproxied) resource class
> Object o = ... // obtain the Guice-based instance.
> Object value = ...
> f.set(o, value);
>
> Paul.
>
> On Nov 24, 2008, at 6:33 PM, Gili wrote:
>
> >
> >
> > Paul Sandoz wrote:
> >>
> >> The important point here is that the returned instance can be
> >> injected
> >> on by Jersey correctly. That is why the method is called
> >> getInjectableInstance. The single use-case that has been driving this
> >> so far has been Spring-AOP, where proxy by encapsulation can occur
> >> rather than proxy by extension (see snippet of Spring-based code at
> >> end of email).
> >>
> >> Given an instance of Foo and an instance of Foo$$EnhancerByGuice$
> >> $45c70c66 are the fields on the class Foo accessible and can those
> >> fields be modified when given an instance of Foo$$EnhancerByGuice$
> >> $45c70c66. If so then getInjectableInstance can just return the
> >> instance that is passed in.
> >>
> >
> > Unfortunately this won't work. I just fired up the debugger against
> > Guice
> > proxies and it seems I was right the first time around. Guice is
> > using CGLIB
> > to construct proxies that contain the data directly instead of
> > redirecting
> > method calls to an unproxied class.
> >
> > If I were to simply return o, Jersey wouldn't be able to find the
> > @Path
> > annotation because the proxy subclass does not contain it.
> >
> > I am suggesting the following:
> >
> > 1) Proxy by encapsulation (proxy methods redirect to unproxied object)
> >
> > Class<?> getInjectableClass(Object original)
> > {
> > return getInjectableObject(original).getClass();
> > }
> >
> > Object getInjectableObject(Original original)
> > {
> > // return unproxied object
> > }
> >
> > 2) Proxy by extension (proxy contains actual data)
> >
> > Class<?> getInjectableClass(Object original)
> > {
> > return original.getClass().getSuperclass();
> > }
> >
> > Object getInjectableObject(Original original)
> > {
> > return original;
> > }
> >
> > Jersey would then look up @Path and other annotations on the class
> > returned
> > by getInjectableClass() and inject into the object returned by
> > getInjectableObject().
> >
> > The only thing I don't like about the above methods is that Spring's
> > implementation of getInjectableClass() needs to invoke
> > getInjectableObject()
> > a second time. Ideally we want a single method that returns both
> > Class and
> > Object at the same time.
> >
> > Gili
> > --
> > View this message in context:
> http://n2.nabble.com/Simplifying-Jersey-life-cycle-and-IoC-integration-tp1367641p1572951.html
> > Sent from the Jersey mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1573501&i=0>
> > For additional commands, e-mail: users-help@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1573501&i=1>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1573501&i=2>
> For additional commands, e-mail: users-help@...
> <http://n2.nabble.com/user/SendEmail.jtp?type=node&node=1573501&i=3>
>
>
>
> ------------------------------------------------------------------------
> This email is a reply to your post @
> http://n2.nabble.com/Simplifying-Jersey-life-cycle-and-IoC-integration-tp1367641p1573501.html
> You can reply by email or by visting the link above.
>
--
View this message in context: http://n2.nabble.com/Simplifying-Jersey-life-cycle-and-IoC-integration-tp1367641p1573512.html
Sent from the Jersey mailing list archive at Nabble.com.