[seam-dev] Seam and RESTEasy integration

[Christian Bauer]

On Jul 13, 2008, at 15:04 , Ryan J. McDonough wrote:

> Cool! I'm very interested as to how this is being implemented. Also,  
> is this integration going to be part of Seam, RESTEasy, or as a sub- 
> module of RESTEasy?

It's going to be part of Seam, planned is a seam-resteasy.jar that you  
simply drop into your libs (in addition to any resteasy JARs). That's  
how other frameworks and libs are integrated with Seam today. So I  
guess we need a RESTEasy dependency in the Seam POMs to compile it  
(Pete?).

Same for configuration: Any @Provider and @Path classes are  
automatically discovered during Seam application startup when the  
RESTEasy libs are in the classpath. If you want to customize settings,  
you override a built-in Seam component in a Seam configuration file  
(many deployment options here, this is just one of them):

     <component name="resteasyApplicationConfig" precedence="20"
                 
class="org.jboss.seam.resteasy.ResteasyApplicationConfig">
         <property name="scanForResources">
             <value>false</value>
         </property>
         <property name="resourceClassNames">
             <value>my.CatalogResource</value>
             <value>my.ItemResource</value>
         </property>
         ... and so on ...
     </component>

This Seam component supports all the other settings you'd have in  
web.xml with plain RESTEasy. You do not have to touch web.xml at all  
with this approach. This Seam component is an extension of the JAX-RS  
ApplicationConfig. (By the way, this should be an interface, not an  
abstract class... tell the "experts".)

So that allows you to run your existing @Path and @Provider classes in  
a Seam app without any additional configuration or changes. Drop the  
classes into the classpath and Seam will serve HTTP requests through  
its existing resource-loading architecture (the SeamResourceServlet is  
enabled in all Seam applications). You can even hook into that request  
processing and customize the dispatcher, wrap the request, and so on.  
This is regular Seam stuff.

Of course people want that integration not only for integrated  
bootstrap and request processing but for the Seam programming model  
when writing resources and providers:

1. You can put an @Name onto your @Path root resource class. This  
enables Seam lifecycle management for the resource object. If it is  
ScopeType.EVENT you basically get the JAX-RS default (POJO per  
request) lifecycle. If it is ScopeType.APPLICATION, you get Singleton  
lifecycle - you can also put @Synchronized on it. And so on for  
ScopeType.SESSION and ScopeType.CONVERSATION. Once your resource  
classes and providers are Seam components, you get full Seam  
interception for @In(jection), and so on. E.g. you can use @In ItemDAO  
on a field in your resource implementation.

2. You can put @Name on your @Provider class. It has to be  
ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS  
providers I need an extension to RESTEasy. I need to tell RESTEasy how  
it should look up an instance of a Provider from Seam at runtime.  
Right now you guys only support setProvider(clazz) and  
setProviderInstance(o) at bootstrap. I need  
setProviderLookup(anImplementationOfALookupInterface) or something  
similar.

3. We'll probably have a mechanism for transporting conversation  
identifiers in HTTP headers. However, I'm thinking that the way this  
should be implemented is with explicit automatically created resources  
that identify a particular conversation "workspace". See Bill's blog  
about JMS integration and how you'd model a transaction resource  
RESTfully. This is the same approach just for Seam conversations.

4. In a second stage we might want to integrate the Seam Application  
Framework. This is a basic CRUD framework, today used for quick  
development of JSF apps. We can use this as a foundation to expose  
entity lists and instances for CRUD/search directly from the database  
as HTTP resources. Similar to what Rails does out of the box, just  
nicer :)

5. I'm thinking about a special provider that can marshal an object  
graph into an XHTML (not just XML) response body and back from an  
XHTML request body to an object graph. This is about the  
"connectedness" of resources, see the O'Reilly REST book. As a  
developer I should write a Facelets XHTML template that defines the  
transformation. Imagine that you write it the same way you write a JSF  
template today, with bidirectional binding using EL expressions, from  
object getter/setter pair to XML attribute or element value. We can  
even have built-in Facelets "widgets" that render certain  
microformats. Seam has some machinery for this already but we might  
need an extra interceptor on resource methods to trigger the  
transformation. Or we use Seams pages.xml navigation rules ("when this  
resource method finishes, render this template"). Bill, I'm not sure  
we even need anything in RESTEasy for that, Seam intercepts these  
things anyway if there is a @Name on the class.

Bootstrap, request servicing, and objectives 1 and 2 I already  
implemented locally. Let's get the provider lookup for 2 done and I  
can commit something into Seam trunk. We'll talk about 3, 4, and 5  
later.