Hi Martin,
Perhaps we could pass a ComponentContext to a new getInstance method:
<T> T getInstance(ComponentContext cc, Scope scope, Class<T> c)
This ComponentContext could present the AccessibleObject, Annotation[]
and Annotation (if any are present).
I think it necessary that @Inject would need to be modified anyway if
you want to support it on constructor/method params, since the parameter
name is not available (plus there is no direct accessible object, the
closest is the constructor or method).
This ComponentContext is similar to
com.sun.jersey.spi.inject.InjectableContext so we could unify that.
Paul.
Martin Grotzke wrote:
> Hi,
>
> the @Inject has currently one limitation: it just can fetch a bean based
> on the field's type. E.g. when we have this resource:
>
> @Path("/foo")
> class Resource {
> private @Inject Properties _props1;
> ....
> }
>
> the ComponentProvider will be asked for a bean of type Properties. If
> there are two beans of type Properties configured in the spring
> applicationContext (or the IoC-config), the ComponentProvder cannot
> decide which bean to return and therefore will fail.
>
> Regarding the spring-integration it would be good to get some
> information about the @Inject annotation or even the field.
>
> Then one could extend @Inject with some "value" or "hint" property that
> can be evaluated by the ComponentProvider, of, if the field would be
> handed to the CP, one could e.g. use the field.name as a hint regarding
> the desired bean. I would prefer the first option, as it's more explicit
> and more self-explaining.
>
> I think we have two choices:
> 1) Extend the ComponentProvider
> 2) Create some @InjectBean annotation just for the spring-integration
> that will be handled by the SpringComponentProvider
>
> What do you think?
>
> Cheers,
> Martin
>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109