On Nov 24, 2008, at 9:07 PM, Gili 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.
>
For application-based code i am not sure we can do much. However, I
still do not understand why it is more important for Guice.
You said:
Jersey would then look up @Path and other annotations on the class
returned
by getInjectableClass() and inject into the object returned by
getInjectableObject().
I said:
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 why for Guice does the above not apply or fail?
AFAICT the problem you are stating with application-based code wth
UriInfo is slightly different to getting the IoC integration working.
Have you tried writing a Guice-based IoCComponentProviderFactory?
perhaps it would be easier to share some code and a simple maven-based
example around this, because i am finding it hard to discuss in the
abstract.
Paul.
> 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.