[seam-dev] Re: [Resteasy-developers] Seam and RESTEasy integration

[Ryan J. McDonough]

On Jul 13, 2008, at 9:44 AM, 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?).
>
> 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".)

We'll take it up.  BTW, IIRC, this class may be renamed to  
"Application" in a future release of the spec.

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

Nice!

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

Can you open a JIRA issue on that and assign it me?

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

I'm not sure what Rails does, but maybe I'm thinking along the same  
lines:

http://www.damnhandy.com/2008/07/02/resteasy-and-seam/

One thing I have been trying to look at is how to access nodes of a  
object graph without having to create a resource class for every child  
entity. Some of the Jersey examples do this and this would get  
cumbersome very quickly for a reasonably sized object graph.

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

Excellent!

>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Resteasy-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers