Why not use RESTeasy to create REST services?
After few days using RESTeasy in my project I found a very annoying issue related with its Spring support, please consider the bean declaration below:
1 2 3 4 5 6 | <bean id="remoteAuthenticationService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"> <property name="serviceUrl" value="http://${host}:${port}/adminserver/remoteAuthenticationService.esp"/> <property name="serviceInterface" value="com.fastsearch.esp.admin.RemoteAuthenticationService"/> <property name="httpInvokerRequestExecutor" ref="executor"/> </bean> |
For some reason the RESTeasy ContextLoaderListener implementation is unable to resolve property placeholders used by some properties of beans at singleton scope, when I read these properties from my bean logic I see all properties placeholders there as they weren’t resolved.
So I decided to try Jersey since it uses the standard implementation of ContextLoaderListener that comes with Spring, now my application works as expected, all properties placeholders are being correctly resolved on my Spring singleton beans.
Posted by rogerio |
Comments (2)
Loading ...
It’s a shame that you moved to Jersey because of Spring support. I worked pretty hard to get a better Spring/RESTEasy integration. Since 0.9, you can use standard Spring, including the Spring DispatcherServlet. I’ll take a look at the problem you’re experiencing.
February 11th, 2009 | #
And to be honest, this tomcat context doesn’t contains only the REST service, it also has a JSF webapp, both uses Spring, the JSF will share the same ContextLoaderListener implementation that comes with RESTeasy and the property placeholders issue happens everywhere, in singleton beans used by REST services and singleton beans used by JSF webapp too.
February 11th, 2009 | #