On Nov 10, 2008, at 10:09 AM, Paul Sandoz wrote:
> But that assumes the bean name is already known.
>
> Since the Spring developer has registered spring beans in the
> applicationContext.xml or via autowiring it would be good if we
> could somehow obtain from Spring all registered bean descriptions
> and then we could analyze which ones are provider/resource classes.
> Currently we do that by Jersey scanning for classes, which is
> redundant for the case of Spring registered stuff.
>
> From browsing the Spring API it is possible to obtain all the bean
> definition names from ListableBeanFactory and then the type can be
> obtained from BeanFactory. But i do not know how consistent this all
> is, from reading the doc of ListableBeanFactory, there may be
> circumstances where this is not possible.
>
Looks like i an do this:
String[] names = springContext.getBeanDefinitionNames();
for (String name : names) {
Class type = springContext.getType(name);
...
}
and i verified it for the tests we have.
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).
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
>