[seam-dev] Seam and RESTEasy integration

[Pete Muir]

On 13 Jul 2008, at 14:44, Christian Bauer wrote:

>
> 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?).

I will create a module in a bit.

> 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>

We should have the namespaced version as well:

<reasteasy:reasteasy-application-config scan-for-resouces="false">
    <resteasy:resource-class-names>
       <value>my.CatalogResource</value>
       <value>my.ItemResource</value>
    </resteasy:resource-class-names>
</resteasy:resteasy-application-config>

(btw the precedence isn't necessary, components default to precedence  
40)

>
>
> 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.

So this would be similar to named conversations? You have to  
explicitly define and use a conversation?

> 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 :)

Nice.

> 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.

Yup, I think this nice. I don't see any particular difficulties  
assuming Seam can intercept the calls correctly. You could perhaps do  
the mapping using pages.xml, or an annotation.

I assume you would build (4) on (5)?

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete