users@jersey.java.net

Testing jersey-spring with profiles [WAS: Re: [Jersey] Registration of resource/provider classes via Spring]

From: Martin Grotzke <martin.grotzke_at_freiheit.com>
Date: Tue, 11 Nov 2008 10:36:12 +0100

On Mon, 2008-11-10 at 10:50 +0100, Paul Sandoz wrote:
> On Nov 10, 2008, at 10:09 AM, Paul Sandoz wrote:
>
> Interestingly it appears the spring20 profile is never tested, maven
> tests the spring25 profile twice. I am guessing the spring20 profile
> was never tested because at least for me using maven 2.0.9 the
> compilation does not exclude the spring25 dependent tests from
> compilation and therefore fails (even though exclusion is declared).
Why does it not exclude these tests?

I'm also using maven 2.0.9 and "mvn -Pspring20 test" only runs the
spring-2.0 tests. This achieved by the surefire-plugin configuration:
- <exclude>**/spring25/*.java</exclude>
- the system property resourcePackages = com.sun.jersey.spring

To run both spring20 and spring25 tests you need to
- mvn -Pspring20 test
- mvn -Pspring25 test

Cheers,
Martin


>
> Paul.
>
>
>
> >
> >>> If so those
> >>> classes could be analyzed by Jersey and registration of those
> >>> classes
> >>> could occur. In such cases Jersey scanning could be disabled unless
> >>> one explicitly declares it and wants to mix Spring and non-Spring
> >>> beans.
> >> Sounds good to me.
> >>
> >> So we would introduce a new SpringResourceConfig that is provided
> >> by the
> >> SpringServlet if the user did not specify any init param related to
> >> the
> >> resourceConfig (resourceConfigClass, application, packes, classpath)?
> >>
> >
> > Quite possibly. Although that requires that such a config has some
> > spring context associated with it. So it may be the servlet can just
> > augment an existing resource config with provider/resource classes.
> >
> >
> >>>
> >>> I guess the problem is a little more complicated since there is not
> >>> always a one to one correspondence between the class and the
> >>> instance
> >>> but i think that is a fair assumption to make for resource and
> >>> provider classes.
> >> What do you mean with this?
> >>
> >
> > That was related to my mis-understanding with spring bean names in
> > the applicationConfig.xml. I think the restriction is much clearer
> > now: there can be only one bean per resource or provider class.
> >
> > Thanks,
> > Paul.
> >
> > ---------------------------------------------------------------------
> > 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

-- 
Martin Grotzke
http://www.javakaffee.de/blog/