On Nov 24, 2008, at 9:38 PM, Gili wrote:
>
> Sorry Paul. I just reread your post and clearly I missed
> your point.
> Yes, the mechanism you describe should work for both Guice and Spring
> but I'm talking about IoC causing failure much later on in the code.
>
OK, i think we are in agreement page now :-)
BTW i verified the the case for Spring does as you point out.
> The problem is that UriBuilder does not make use of
> IoCComponentProviderFactory at all. Once you start going down that
> road
> I believe you will agree we need some form of getInjectableClass().
>
I see your point. Is this not part of a larger issue in that CGLIB
does not preserve annotations? Are we not attempting to work around a
bug in CGLIB in this respect?
Paul.
> Gili
>
> cowwoc wrote:
>
> >
> > 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: Re: [Jersey] Simplifying Jersey life-
> cycle and IoC integration
> Sent from the Jersey mailing list archive at Nabble.com.