Hi Paul,
I just had a look at the code that registers known spring beans - looks
good. I only changed
Class type = springContext.getType(name)
to
Class type = ClassUtils.getUserClass( springContext.getType(name) );
(see [1]) so that we get the real type in case of a CGLIB-generated
subclass and pass this to the ResourceConfig for further examination.
I found this when I just wrote a test for the getInjectableInstance
stuff as you suggested - good catch :)
The other changes (IoCProviderFactory, IoCResourceFactory,
SingletonWrapper etc.) are rather heavyweight, it feels as if I had not
touched jersey for months ;)
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?
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/