Hi James,
Another problem is if the resource instance is not managed then we do
not know the scope of that instance, it could be even a static
instance (bad practice i know!),
Thus probably the only reliable thing we can do under these
circumstances is perform field injection (no setter method injection)
of singleton dependencies, which would include all of the @Context you
require plus what Jersey additional defines (or what the user adds
too). Jersey's injection support will not inject if a field value is
non-null.
Hence we could have init param to support this a re-injection of
fields should not have any side effects if it has occurred already.
Can you log an issue?
Paul.
On Apr 20, 2010, at 6:24 PM, James Strachan wrote:
> On 20 April 2010 16:39, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>> Hi James,
>>
>>>> Injecting after instantiation sort of breaks the life-cycle
>>>> contract
>>>> (injection onto fields or setter methods should occur after
>>>> construction
>>>> and
>>>> before any post construct method is invoked).
>>>
>>> Though if I'm creating the sub resource object by hand, there will
>>> be
>>> no post construction method invoked anyway - we're already outside
>>> of
>>> the IoC post construction rules, since the IoC container isn't
>>> creating the object - we're just invoking a constructor on the
>>> object.
>>>
>>> It would be nice to be able to enable JAXRS injection into sub
>>> resources - maybe as an optional extension?; it would leave the code
>>> more dry. I find when creating sub resources I tend to create a
>>> custom
>>> constructor for the root resource to invoke to keep code small &
>>> DRY.
>>> It does seem a bit odd that you can share a base class/trait
>>> between a
>>> root and sub resource and its not possible to have any of the
>>> injections fire in the sub resources.
>>>
>>> I wonder how hard it'd be to add as an option? I remember seeing in
>>> both Guice and Spring for example a one line method call to perform
>>> any remaining injections on an object if you create it outside of
>>> the
>>> IoC container?
>>>
>>
>> One problem is for the code that processes the return instance from
>> the
>> sub-resource locator to determine whether the returned instance is
>> managed
>> or not (it could be managed by Jersey, Guice, Spring, CDI or
>> whatever is
>> plugged in). As we do not want to perform re-injection.
>
> Ah I see...
>
> I was actually only thinking of just the JAXRS/Jersey injection here,
> not arbitrary Spring/Guice stuff. e.g. injecting @Context stuff only
> (servletContext, request parameters and all that jazz).
>
>
>> Currently there is no way in Jersey to determine if an instance is
>> managed,
>> or if the class of the instance is "in-scope". Is it possible in
>> Guice/Spring/CDI to determine that?
>
> Not too sure. It sounds a bit tricky. I've seen cases with Spring and
> Guice in the past where they can create an instance of type X
> (injecting its dependencies) without X being defined in the
> configuration (spring XML or guice modules) so I guess that might be
> hard.
>
>
>> If we can assume the case of when the instance is not managed it is
>> reasonably easy to support injection. Perhaps we could support an
>> annotation
>> on a sub-resource locator and leave it up to the developer to do
>> the right
>> thing? We could also expose out the injection support in
>> ResourceContext.
>>
>> ResourceContext.inject(Object o);
>>
>>
>> I would really like a type safe way of doing constructor injection
>> with
>> additional parameters but have not worked out a way that could be
>> like
>> Guice's assisted inject and work across the DI containers.
>
> How about if we only consider the JAXRS injections via @Context;
> allowing those to be injected on sub resources via an optional flag in
> Jersey?
>
> I guess if you did create the object via Guice/Spring then that have
> already done the JAXRS injections already. I guess in the grand scheme
> of things doing the @Context injection twice is not a huge biggie -
> plus am sure we could eventually keep a little cache of objects we've
> injected to avoid doing it twice. Maybe using an annotation on each
> sub resource might be more specific?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>