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.
Great!
I currently need a lot of my time for my (growing) family, therefore I
cannot do as much here as I would like to do.
As soon as I find some time I'll have a closer look :)
Cheers,
Martin
>
> 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