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?
>
>
> > 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.
> > 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.
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...
Cheers,
Martin
>
> Paul.
>
> > Here's the stack trace:
> > java.lang.InstantiationException: javax.ws.rs.ext.ContextResolver
> > at java.lang.Class.newInstance0(Class.java:340)
> > at java.lang.Class.newInstance(Class.java:308)
> > at com.sun.ws.rest.impl.application.WebApplicationImpl
> > $AdaptingComponentProvider.getInstance(WebApplicationImpl.java:280)
> > at com.sun.ws.rest.impl.application.WebApplicationImpl
> > $3.getInjectableValue(WebApplicationImpl.java:251)
> > at com.sun.ws.rest.spi.resource.Injectable.inject(Injectable.java:58)
> > at
> > com.sun.ws.rest.impl.application.WebApplicationImpl.injectResources
> > (WebApplicationImpl.java:260)
> > at
> > com.sun.ws.rest.impl.application.WebApplicationImpl.injectResources
> > (WebApplicationImpl.java:218)
> > at com.sun.ws.rest.impl.application.WebApplicationImpl.access$300
> > (WebApplicationImpl.java:99)
> > at com.sun.ws.rest.impl.application.WebApplicationImpl
> > $AdaptingComponentProvider.getInstance(WebApplicationImpl.java:281)
> > at
> > com.sun.ws.rest.impl.application.ComponentProviderCache.getComponent
> > (ComponentProviderCache.java:89)
> > at
> > com.sun.ws.rest.impl.application.MessageBodyFactory.getProviderMap
> > (MessageBodyFactory.java:106)
> > at com.sun.ws.rest.impl.application.MessageBodyFactory.<init>
> > (MessageBodyFactory.java:81)
> > at com.sun.ws.rest.impl.application.WebApplicationImpl.initiate
> > (WebApplicationImpl.java:411)
> >
> >
> > 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?
> >
> > Cheers,
> > Martin
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net