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

[Bill Burke]

Ryan J. McDonough wrote:
> 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?
> 

We should just rename ResourceFactory to ComponentFactory and use that SPI.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com