On Mon, 2008-04-14 at 10:28 +0200, Jean Aurambault wrote:
> Martin Grotzke wrote:
> > On Fri, 2008-04-11 at 10:28 +0200, Paul Sandoz wrote:
> >> On Apr 11, 2008, at 9:23 AM, Martin Grotzke wrote:
> > 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, "/*");
Ahh, good to know, thanx :)
With the spring servlet it looks like this:
final Map<String,String> contextParams = new HashMap<String, String>();
contextParams.put( "contextConfigLocation", "classpath:applicationContext.xml" );
context.setInitParams( contextParams );
final ServletHolder springServletHolder = new ServletHolder( ContextLoaderServlet.class );
springServletHolder.setInitOrder( 1 );
context.addServlet( springServletHolder, "/*" );
Cheers,
Martin
>
>
> 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
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net