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