That works OK, so long as you're not using proxies for other things,
like Spring DAO transaction management.
The "lookup-method" there will create a cglib based proxy, which has
potential to conflict if you have other cglib based proxies working in
your configuration. I know for a fact this does not work when I'm using
Springs transaction management functionality, for example.
Or, possibly one doesn't want the cglib dependency at all.
So, yes that's also a solution. But, it's not the simple (preferred?)
"spring way."
Adam
Jonathan Hall wrote:
org.restlet.ext.spring_2.0 has SpringFinder. So it's a case of :
<bean id="my" class="org.restlet.ext.spring.SpringFinder">
<lookup-method name="createResource" bean="myResource"/>
</bean>
<bean id="myResource" class="com.blah.myResource" scope="prototype"/>
I use restlet via a servlet, I have to jump through some hoops but it
can mostly be wired via spring.
Jon
Adam Taft wrote:
Kim,
One of the "bigger" problems you'll have (in my opinion) is
integration of Restlet's Resource classes within your Spring
framework. A Restlet Resource will generally be the class you'll want
talking to your spring backend (like your spring DAOs, etc.).
However, the Resource instances are created per request in a stateful
manner (not stateless like a traditional spring bean). So, you have
to play some tricks.
To get around this, you'll need to use a custom Finder class. Various
people have contributed different implementations of Finder which
works with Spring. I've got one posted in a previous email which
you're free to use (or I can send it to you).
Jerome has made a lot of changes which will help in configuring
Spring. I think most of these changes are in the 1.1 branch, but they
may be in the main 1.0 branch as well. Not sure. But, he's added a
lot of traditional getter/setter methods (javabean style). So, that
helps a lot. But, you'll still have to deal with Resource instances
being created per request by the Restlet framework.
Yes, you are right though. There is no real reason for the
SpringContext. You can use your spring configuration file to map your
urls to the right Restlet (Filter, Router, Finder, etc.). So, I don't
think you're missing anything there.
Hope this helps,
Adam
Kim Pepper wrote:
I'm just starting out with the Restlet framework after reading the
excellent
RESTful Web Services book. I've had a lot of experience with Spring
MVC and
Hibernate web applications, but it doesn't cut it for RESTful web
applications.
However, I want to reuse the spring managed objects and Data Access
Objects
from my existing projects. I also want to remove the dependency on
Servlets
and use the Restlet framework supported by Jetty or AsyncWeb.
I'm confused by the need for the SpringContext? I assume you can just
create
a
ClassPathXmlApplicationContext passing the applicationContext.xml.
All you
need is the map of url => SpringFinder beans for each of your
resources. Am
I missing something?
Also, has anyone tried wiring an entire application with Spring? A few
BeanFactory's here and there would do the trick!
-- Kim
