On Nov 15, 2008, at 12:58 AM, Martin Grotzke wrote:
> AFAICS amongst others the support of IoC scoped beans changed: before
> there was an explicit support for springs "request" scope via the
> SpringResourceProvider (mapping spring "request" to jerseys
> PerRequest).
> AFAICS you now abstracted this with the UndefinedMapper, so that such
> scopes now are deferred to the IoC container, right?
>
I am planning to fix this.
Paul.
> Cheers,
> Martin
>
>
> [1] http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/util/ClassUtils.html#getUserClass(java.lang.Class)
>
>
> On Mon, 2008-11-10 at 13:45 +0100, Paul Sandoz wrote:
>> Hi,
>>
>> I have fixed this in the trunk. It is no longer necessary to declare
>> classes or scanning of in the web.xml, but you can if you wish for
>> backwards compatibility.
>>
>> The web.xml of the spring example is now:
>>
>> <servlet>
>> <servlet-name>Jersey Spring Web Application</servlet-name>
>> <servlet-
>> class>com.sun.jersey.spi.spring.container.servlet.SpringServlet</
>> servlet-class>
>> <!-- The following initialization parameter is only required
>> for
>> registering Jersey managed classes. Spring-managed
>> classes
>> are automatically registered.
>> -->
>> <init-param>
>> <param-name>com.sun.jersey.config.property.packages</
>> param-name>
>> <param-
>> value
>>> com.sun.jersey.samples.springannotations.resources.jerseymanaged</
>> param-value>
>> </init-param>
>> <load-on-startup>1</load-on-startup>
>> </servlet>
>>
>> it declares a package to scan for Jersey-managed root resource and
>> provider classes. It is not necessary to include the package
>> "com.sun.jersey.samples.springannotations.resources" as spring
>> already
>> knows about such classes and Jersey asks Spring for what it knows.
>>
>> Paul.
>>
>> On Nov 10, 2008, at 10:09 AM, Paul Sandoz wrote:
>>
>>>
>>> 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.
>>>
>>> ---------------------------------------------------------------------
>>> 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/