Martin Grotzke wrote:
> On Fri, 2008-04-11 at 10:28 +0200, Paul Sandoz wrote:
>> Hi Martin,
>>
>> On Apr 11, 2008, at 9:23 AM, Martin Grotzke wrote:
>>
>>> Hi Paul,
>>>
>>> yesterday I started to write tests for the spring-integration (using
>>> embedded jetty as you posted some weeks ago, which is really cool
>>> btw :)).
>>>
>> Great. (BTW i plan to switch to Grizzly for embedded servlet testing
>> after the 0.7 release).
> Ok. With jetty it took some time for me to notice that I have to use the
> spring servlet for spring initialization - I didn't find out how to
> configure a servlet context listener. Hopefully with Grizzly this is
> easier then :)
>
> Just for interest: in what is Grizzly better than Jetty?
>
The Grizzly community is very active, helpful and fixes things really
fast, and we just need to put one jar in the distribution. Plus i want
to use Grizzly for comet support.
>>
>>> When doing this I noticed, that WebApplication.initiate fails when
>>> injectResources is invoked for XMLJAXBElementProvider (which inherits
>>> the field
>>> @Context private ContextResolver<JAXBContext> cr;
>>> from AbstractJAXBElementProvider).
>>>
>>> How is this realized, how can I test on this case? The issue is,
>>> that I
>>> currently try to get an instance of a @Context annotated field, if
>>> there's no type->injectable mapping existing for the field type.
>>>
>> Developers can register stuff like this:
>>
>> @Provider
>> public class MyResolver implements ContextResolver<JAXBContext> {
>> }
>>
>> and an aggregated instance of such providers will be added to the
>> list of injectables (see the WebApplicaitonImpl.init method). In
>> general a developer can add a resolver for any type. If there are no
>> such providers then no injectable will be registered and thus it will
>> be null. We should not defer to the component provider for types of
>> ContextResolver (off the top of my head i cannot recall if there are
>> others as well).
> Hopefully not :)
> So for now I don't inject @Context annotated fields if the field type is
> ContextResolver.
>
OK.
>>> Another possibility would be to use the annotation->injectable
>>> thing for this, another would be to use another annotation than
>>> @Context.
> What do you think about this? I'm not completely happy with the "inject
> instances pulled from the component provider if the field is annotated
> with @Context and we don't have better alternatives"-thing as it seems
> to me to be somehow magic - or not very stable. I'm just not sure and
> wanted to raise the question again.
That is OK, we have run into some issues so i think you are right to
raise it.
> If we would use the annotation-injectable way the spring-integration
> module could define it's own @Inject annotation and inject beans pulled
> from spring. The disadvantage is, that this logic has to be duplicated
> for different IoC-backends...
>
My understanding is there are two requirements:
1) Support annotation-based injection on fields for IoC frameworks that
do not have such capability; and
2) Support constructor/method parameter injection of IoC registered
instances.
Given that we ran into an issue with using @Context for 1) then perhaps
we should have a different annotation like you proposed that is clearly
separate from @Context. If we make changes to Injectable it should easy
to support, and that way we also support Frank's requirements.
For 2) we still require are our own annotation, as i don't see any
features in Guice/Spring to allow intermixing of parameter injection
responsibilities (that could change as we learn more).
So i think i am leaning towards the following:
1) Supporting injectable per annotation and injectable per
annotation+type;
2) Use a new annotation as you previously said (you were right!)
to specify deferring to an IoC framework;
3) Implement an injectable per annotation, from 1), for 2); and
4) Implement a parameter injectable for 2).
Sound like a plan?
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109