Menu
▾
▴
resteasy-developers
|
From: Bill B. <bb...@re...> - 2008-07-11 15:40:45
|
FYI, Christian Bauer is doing the Seam integration for Resteasy. It is mostly done. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ryan J. M. <ry...@da...> - 2008-07-13 13:04:39
|
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? Ryan- On Jul 11, 2008, at 11:40 AM, Bill Burke wrote: > FYI, Christian Bauer is doing the Seam integration for Resteasy. > It is > mostly done. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > ------------------------------------------------------------------------- > 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 > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2008-07-13 16:40:55
|
Its going to be part of Seam, from what Christian tells me. I don't know the best place to keep the code though. A stable SPI would allow us to keep the code in Seam, but if we start adding special configuration options, we may need to move the integration to Resteasy. 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? > > Ryan- > > On Jul 11, 2008, at 11:40 AM, Bill Burke wrote: > >> FYI, Christian Bauer is doing the Seam integration for Resteasy. It is >> mostly done. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> ------------------------------------------------------------------------- >> 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 >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Christian B. <chr...@gm...> - 2008-07-13 13:44:41
|
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".)
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.
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 :)
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.
|
|
From: Ryan J. M. <ry...@da...> - 2008-07-13 17:36:58
|
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 > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2008-07-14 01:06:27
|
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 |
|
From: Christian B. <chr...@gm...> - 2008-07-14 09:46:37
|
On Jul 13, 2008, at 19:36 , Ryan J. McDonough wrote: >> 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? http://jira.jboss.com/jira/browse/RESTEASY-79 I need one other thing, maybe you have that as an API already: When a request hits the SeamResourceServlet, the mapped path (configurable in Seam though) is: /seam/resource/rest/<whatever> Unfortunately, that means you have to use this in your resources: @Path("/seam/resource/rest/catalog/item/123") It would be much nicer if users could skip the /seam/resource/rest part of the path. I could use HttpServletRequestWrapper before passing the call to dispatcher.invoke() and override all methods that return the path. It would be much better if we could tell RESTEasy to map @Path with a customizable base. |
|
From: Bill B. <bb...@re...> - 2008-07-14 12:47:32
|
Christian Bauer wrote: > On Jul 13, 2008, at 19:36 , Ryan J. McDonough wrote: > >>> 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? > > http://jira.jboss.com/jira/browse/RESTEASY-79 > > I need one other thing, maybe you have that as an API already: > > When a request hits the SeamResourceServlet, the mapped path > (configurable in Seam though) is: > > /seam/resource/rest/<whatever> > > Unfortunately, that means you have to use this in your resources: > > @Path("/seam/resource/rest/catalog/item/123") > > It would be much nicer if users could skip the /seam/resource/rest > part of the path. I could use HttpServletRequestWrapper before passing > the call to dispatcher.invoke() and override all methods that return > the path. It would be much better if we could tell RESTEasy to map > @Path with a customizable base. > The Dispatcher is driven off of UriInfo. So, you need to build your own since it is specific to Seam. Look in HttpServletDispatcher to see how it builds it, its pretty easy and the methods are already there. FYI, you should be working off of trunk as we've have recently changed packaged names (to org.jboss.resteasy) and are refactoring continuously. You will also want to take advantage of our interceptor model when we get it in. Do you want SVN access? Just send me your sf.net id privately and I'll give it to you. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Christian B. <chr...@gm...> - 2008-07-14 12:59:38
|
On Jul 14, 2008, at 14:47 , Bill Burke wrote: > The Dispatcher is driven off of UriInfo. So, you need to build your > own since it is specific to Seam. Look in HttpServletDispatcher to > see how it builds it, its pretty easy and the methods are already > there. OK, I'll try that. > FYI, you should be working off of trunk as we've have recently > changed packaged names (to org.jboss.resteasy) and are refactoring > continuously. You will also want to take advantage of our > interceptor model when we get it in. Well let's keep integration for releases, we can't refactor every day to follow your nightly snapshots. Just open a JIRA issue on Seam when you have a new release and you think that the integration needs to be updated. We most likely won't need your interceptors and I'm not sure you should even have them in RESTEasy. KISS and if people want a resource programming model that supports interception they should use Seam (or EJB3, or Spring, or whatever other container). |
|
From: Bill B. <bb...@re...> - 2008-07-14 14:32:54
|
Christian Bauer wrote: > On Jul 14, 2008, at 14:47 , Bill Burke wrote: > >> The Dispatcher is driven off of UriInfo. So, you need to build your >> own since it is specific to Seam. Look in HttpServletDispatcher to >> see how it builds it, its pretty easy and the methods are already >> there. > > OK, I'll try that. > >> FYI, you should be working off of trunk as we've have recently >> changed packaged names (to org.jboss.resteasy) and are refactoring >> continuously. You will also want to take advantage of our >> interceptor model when we get it in. > > Well let's keep integration for releases, we can't refactor every day > to follow your nightly snapshots. Just open a JIRA issue on Seam when > you have a new release and you think that the integration needs to be > updated. > > We most likely won't need your interceptors and I'm not sure you > should even have them in RESTEasy. KISS and if people want a resource > programming model that supports interception they should use Seam (or > EJB3, or Spring, or whatever other container). > I originally thought this myself, but there are a decent amount of use cases that require them. I'm doing asynch stuff as well as Cache-Control annotations and server-side caching. All of which require interception at certain (and different) points of request processing that Seam can't provide for me. Asynch requires interception before request unmarshalling. Server-side caching requires interception before and after marshalling requests. Cache-Control annotations require knowledge of the HTTP method being invoked. Also, users may want to re-use JAX-RS annotations within their interceptors, for instance, for their own security protocol. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Pete M. <pet...@jb...> - 2008-07-13 14:12:32
|
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
|
|
From: Christian B. <chr...@gm...> - 2008-07-13 14:22:51
|
On Jul 13, 2008, at 16:12 , Pete Muir wrote: >> 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? Yes, it's the same concept. You do a first request to create the conversation workspace under a resource path like /rest/conversation/ editItem and then have sub-resources, like PUT a new representation to /rest/conversation/editItem/123. Shouldn't be difficult, the tricky part is the resource design. Bill summarized the problem and possible solutions here: http://bill.burkecentral.com/2008/06/16/resteasy-mom-an-exercise-in-jax-rs-restful-ws-design/ > I assume you would build (4) on (5)? Well, I'm going to commit (1) and (2) and then let others have a look :) I think Shane should be involved at some point because he knows the current remoting/WS stuff best. |
|
From: Pete M. <pet...@jb...> - 2008-07-13 14:26:10
|
On 13 Jul 2008, at 15:22, Christian Bauer wrote: > > On Jul 13, 2008, at 16:12 , Pete Muir wrote: > >>> 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? > > Yes, it's the same concept. You do a first request to create the > conversation workspace under a resource path like /rest/conversation/ > editItem and then have sub-resources, like PUT a new representation > to /rest/conversation/editItem/123. Shouldn't be difficult, the > tricky part is the resource design. Good :-) > Bill summarized the problem and possible solutions here: > > http://bill.burkecentral.com/2008/06/16/resteasy-mom-an-exercise-in-jax-rs-restful-ws-design/ > >> I assume you would build (4) on (5)? > > Well, I'm going to commit (1) and (2) and then let others have a > look :) I think Shane should be involved at some point because he > knows the current remoting/WS stuff best. > > _______________________________________________ > seam-dev mailing list > sea...@li... > https://lists.jboss.org/mailman/listinfo/seam-dev -- Pete Muir http://www.seamframework.org http://in.relation.to/Bloggers/Pete |
Thanks for helping keep SourceForge clean.
X