On Nov 10, 2008, at 12:01 AM, Martin Grotzke wrote:
> Hi Paul,
>
> On Fri, 2008-11-07 at 11:53 +0100, Paul Sandoz wrote:
>> Hi Martin,
>>
>> I am wondering if we could improve the registration mechanism of
>> Jersey with Spring currently we do the following:
>>
>> 1) In the xml config we require that the spring bean is named as the
>> fully qualified class name.
> I asume you are referring to spring's applicationContext.xml, right?
Yes,
> I'm
> not sure what you want to say with "the spring bean is named as the
> fully qualified class name".
>
> 1) spring beans (bean definitions) have an id/name: you can choose
> it as
> you want. In jersey we can refer to this is/name in @Inject#value. If
> the value is not set we resolve the spring bean by type.
>
> 2) spring beans (bean definitions) have set a fully qualified class
> name. This has nothing to do with the bean id/name.
>
My bad, i went back and looked at the code again:
It does this:
final String names[] = springContext.getBeanNamesForType(c);
>
>>
>> 2) For autowire, Jersey scans and Spring scans, it requires some
>> duplication of package declaration.
>>
>> Do you know if there is any way to get the set of classes or bean
>> class information Spring knows about at initialization?
> Yes, it's possible to get the bean definitions via
> ConfigurableListableBeanFactory#getBeanDefinition(String beanName)
> ([1]).
>
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.
>> 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.