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