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.
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().
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: http://n2.nabble.com/Simplifying-Jersey-life-cycle-and-IoC-integration-tp1367641p1573625.html
Sent from the Jersey mailing list archive at Nabble.com.