JavaDoc jar is now available on line:
http://download.java.net/maven/2/com/sun/jersey/jersey-spring/1.0.1-SNAPSHOT/jersey-spring-1.0.1-SNAPSHOT-javadoc.jar
I wish there was a way to browse the JavaDoc online from the jar in
the maven repo as well.
Paul.
On Nov 10, 2008, at 1:45 PM, 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
>