Ah, I forgot all about about that.
I did run into that problem a while ago when setting it up, now I come
to think of it.
I now use <aop:config> and <tx:advice/> which seems to play nicely with
cglib (for now anyway :)).
Good point.
Adam Taft wrote:
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
