users@jersey.java.net

Re: spring-integration: initiating webapplication fails with _at_Context annotated field in AbstractJAXBElementProvider

From: Jean Aurambault <aurambaj_at_yahoo-inc.com>
Date: Mon, 14 Apr 2008 10:28:37 +0200

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?
>
>
Maybe this can help with jetty:

        ServletHolder serveHolder = new ServletHolder(SpringServlet.class);
        serveHolder.setInitParameter(
                "com.sun.ws.rest.config.property.resourceConfigClass",
                "com.sun.ws.rest.api.core.PackagesResourceConfig");
        
serveHolder.setInitParameter("com.sun.ws.rest.config.property.packages",
"xxxxxxxxxxxxxxxxx");
       
        server = new Server(port);
        Context context = new Context(server, "/", Context.SESSIONS);
        ContextLoaderListener listener = new ContextLoaderListener();
        context.addEventListener(listener);
        context.setResourceBase("src/test/resources");
        context.getInitParams().put("contextConfigLocation",
"classpath:applicationContext.xml classpath:applicationContextTest.xml");
        context.addServlet(serveHolder, "/*");


Jean.
>>
>>> 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
>>
>
>