users@jersey.java.net

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

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 14 Nov 2008 13:59:36 +0100

On Nov 11, 2008, at 10:36 AM, Martin Grotzke wrote:

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

The problem occurs when one does:

   mvn clean -Pspring20 test

because the spring25 related source files are not excluded from the
compilation.

So if i do:

   mvn test

only the default profile, spring25, will be tested and not spring20?

Paul.

> 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/