Menu
▾
▴
resteasy-developers
|
From: Solomon D. <sd...@gm...> - 2008-10-08 19:34:50
|
The current Spring/RESTEasy integration is pretty slick. I'd like to
propose a couple of changes that might make it even better.
1) ResourceExposingService: Expose a spring bean with jax-rs annotations at
different contexts. Think of it as writing code for a sub-resource, and
exposing it via Spring.
Most of the time, one Class maps to one configuration (either Singleton or
Prototype). Sometimes, it may be convenient to have two or more
configurations of the same Class. For example, take a GenericCRUDResource
which does generic crud operations on a specific JPA Entity type which is
also JAXB annotated - GET "/" maps some group list functionality;
GET/PUT/DELETE "/{id} and POST "/" would do the appropriate CRUD operation.
All that GenericCRUDResource needs is a specific Domain Class, an
EntityManager and a unique basePath.
We can do the following in the Spring XML:
<!-- create & configure a book and author GenericCRUDResource -->
<bean class="com.jboss.resteasy.<something>.ResourceExposingService">
<property name="resource" ref="bookResource" />
<property name="basePath" value="/books/" />
</bean>
<!-- spring namespace wrapper -->
<resteasy:expose resource="authorResource" basePath="/authors/" />
The processing of ResourceExposingService is pretty straight forward to add
to SpringBeanProcessor
else if (bean instanceof ResourceExposingService)
{
ResourceExposingService exposer = (ResourceExposingService) bean;
registry.addSingletonResource(exposer.getResource(),
exposer.getBasePath());
}
2) Having RestEasy configured purely in spring, including
configuration/management of the Registry and Dispatcher in Spring - I'll
fill in this idea in a future email.
What do you think about item 1?
-Solomon
|
|
From: Solomon D. <sd...@gm...> - 2008-10-08 19:40:27
|
The current Spring/RESTEasy integration is pretty slick. I'd like to
propose a couple of changes that might make it even better.
1) ResourceExposingService: Expose a spring bean with jax-rs annotations at
different contexts. Think of it as writing code for a sub-resource, and
exposing it via Spring.
Most of the time, one Class maps to one configuration (either Singleton or
Prototype). Sometimes, it may be convenient to have two or more
configurations of the same Class. For example, take a GenericCRUDResource
which does generic crud operations on a specific JPA Entity type which is
also JAXB annotated - GET "/" maps some group list functionality;
GET/PUT/DELETE "/{id} and POST "/" would do the appropriate CRUD operation.
All that GenericCRUDResource needs is a specific Domain Class, an
EntityManager and a unique basePath.
We can do the following in the Spring XML:
<!-- create & configure a book and author GenericCRUDResource -->
<bean class="com.jboss.resteasy.<something>.ResourceExposingService">
<property name="resource" ref="bookResource" />
<property name="basePath" value="/books/" />
</bean>
<!-- spring namespace wrapper -->
<resteasy:expose resource="authorResource" basePath="/authors/" />
The processing of ResourceExposingService is pretty straight forward to add
to SpringBeanProcessor
else if (bean instanceof ResourceExposingService)
{
ResourceExposingService exposer = (ResourceExposingService) bean;
registry.addSingletonResource(exposer.getResource(),
exposer.getBasePath());
}
2) Having RestEasy configured purely in spring, including
configuration/management of the Registry and Dispatcher in Spring, plus
integration with the Spring MVC framework - I'll fill in this idea in a
future email.
What do you think about item 1?
-Solomon
|
|
From: Bill B. <bb...@re...> - 2008-10-08 20:16:54
|
We wouldn't need a ResourceExposingService. That is the Registry. I
see your point of the same class instantiated as different beans, but
having the same relative resource API.
Maybe something as simple as:
public class ResteasyRegistration
{
String getRootPath();
Object getTarget();
}
<bean name="MyBean" class="org.any.MyService"/>
<bean name="MyBean2" class="org.any.MyService"/>
Leave out the @Path annotation on the MyService class.
<bean name="registration" class="org.jboss.resteasy.ResteasyRegistration">
<property name="rootPath">/x/1</property>
<property name="target" ref="MyBean"/>
</bean>
<bean name="registration2" class="org.jboss.resteasy.ResteasyRegistration">
<property name="rootPath">/x/2</property>
<property name="target" ref="MyBean2"/>
</bean>
Then we just modify the Spring adapter to look for instances of
ResteasyRegistration.
Solomon Duskis wrote:
> 2) Having RestEasy configured purely in spring, including
> configuration/management of the Registry and Dispatcher in Spring - I'll
> fill in this idea in a future email.
>
I don't want to be dependent on any IoC container. There are a bunch
out there: Spring, Seam, Guice, JBoss MC, and even Java EE to some
degree. This is why I've focused on configuration via web.xml
context-params.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Solomon D. <sd...@gm...> - 2008-10-08 21:29:09
|
Re ResourceExposingService - I guess it was a bad name... I basically meant
ResteasyRegistration. I do hope this makes it into the RESTEasy core.
Re IoC container dependency: What I really want is a way to use the Spring
MVC framework right along side JAX-RS/RESTEasy. It will allow me to
configure which requests go to Spring MVC Controllers/Struts Actions/JAX-RS
Resources and how to render Views/Producers with
Velocity/Freemarker/Tiles/JSP. In order to get that to work properly, I'll
need to store the Registry et al in the Spring Application context instead
of the ServletContext.
Perhaps I'll just vet some ideas in this group as to how I could use
RESTEasy towards my ends. The means I use to achieve my ends may may be
helpful for other MVC and IoC integrations such as Struts2/Guice... I know
RESTEasy already works with Seam ;).
-Solomon
On Wed, Oct 8, 2008 at 4:16 PM, Bill Burke <bb...@re...> wrote:
> We wouldn't need a ResourceExposingService. That is the Registry. I see
> your point of the same class instantiated as different beans, but having the
> same relative resource API.
>
> Maybe something as simple as:
>
> public class ResteasyRegistration
> {
> String getRootPath();
> Object getTarget();
> }
>
>
>
> <bean name="MyBean" class="org.any.MyService"/>
> <bean name="MyBean2" class="org.any.MyService"/>
>
> Leave out the @Path annotation on the MyService class.
>
> <bean name="registration" class="org.jboss.resteasy.ResteasyRegistration">
> <property name="rootPath">/x/1</property>
> <property name="target" ref="MyBean"/>
> </bean>
>
> <bean name="registration2" class="org.jboss.resteasy.ResteasyRegistration">
> <property name="rootPath">/x/2</property>
> <property name="target" ref="MyBean2"/>
> </bean>
>
> Then we just modify the Spring adapter to look for instances of
> ResteasyRegistration.
>
>
> Solomon Duskis wrote:
>
>> 2) Having RestEasy configured purely in spring, including
>> configuration/management of the Registry and Dispatcher in Spring - I'll
>> fill in this idea in a future email.
>>
>>
> I don't want to be dependent on any IoC container. There are a bunch out
> there: Spring, Seam, Guice, JBoss MC, and even Java EE to some degree.
> This is why I've focused on configuration via web.xml context-params.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
|
|
From: Bill B. <bb...@re...> - 2008-10-09 04:48:33
|
Solomon Duskis wrote: > Re ResourceExposingService - I guess it was a bad name... I basically > meant ResteasyRegistration. I do hope this makes it into the RESTEasy core. > > Re IoC container dependency: What I really want is a way to use the > Spring MVC framework right along side JAX-RS/RESTEasy. It will allow me > to configure which requests go to Spring MVC Controllers/Struts > Actions/JAX-RS Resources and how to render Views/Producers with > Velocity/Freemarker/Tiles/JSP. In order to get that to work properly, > I'll need to store the Registry et al in the Spring Application context > instead of the ServletContext. > Why do you need access to the Registry? And if you really do, can't it be manually registered? > Perhaps I'll just vet some ideas in this group as to how I could use > RESTEasy towards my ends. The means I use to achieve my ends may may be > helpful for other MVC and IoC integrations such as Struts2/Guice... I > know RESTEasy already works with Seam ;). > Yes, please brainstorm. I'm Spring ignorant beyond basic IoC so any insight would be invaluable. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2008-10-09 20:45:59
|
I was thinking about your post here as well as looking at your blog that described various Spring+JAX-RS integration. I think it would be interesting to expand on your ideas. Want to help? I was thinking first step on developing a set of classes that allowed you to define a set of JAX-RS Resources and Providers. Basically what CXF allows you to do and group providers, resources, and configuration options into individual sets. i.e. * A set of providers that apply to a specific set of resources. * A set of providers that apply to only one resource (allows you to override marshalling per resource. * A set of config that applies to a provider and/or a resource * Etc... Creating the classes for this is pretty easy and straightforward. What I don't know how to do is define my own XML namespace/schema and plug it into Spring (or Seam for that matter as I know they have something similar). As a first step, would you be interested in defining/creating that integration? Then we can look at refactoring Resteasy to provide that kind of fine-grain scoping. Bill Burke wrote: > > Solomon Duskis wrote: >> Re ResourceExposingService - I guess it was a bad name... I basically >> meant ResteasyRegistration. I do hope this makes it into the RESTEasy core. >> >> Re IoC container dependency: What I really want is a way to use the >> Spring MVC framework right along side JAX-RS/RESTEasy. It will allow me >> to configure which requests go to Spring MVC Controllers/Struts >> Actions/JAX-RS Resources and how to render Views/Producers with >> Velocity/Freemarker/Tiles/JSP. In order to get that to work properly, >> I'll need to store the Registry et al in the Spring Application context >> instead of the ServletContext. >> > > Why do you need access to the Registry? And if you really do, can't it > be manually registered? > >> Perhaps I'll just vet some ideas in this group as to how I could use >> RESTEasy towards my ends. The means I use to achieve my ends may may be >> helpful for other MVC and IoC integrations such as Struts2/Guice... I >> know RESTEasy already works with Seam ;). >> > > Yes, please brainstorm. I'm Spring ignorant beyond basic IoC so any > insight would be invaluable. > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
Thanks for helping keep SourceForge clean.
X