Wow, lots of development and discussion from when I last checked this thread. We'll check out what's been prototyped and checked in, thanks!
-a- On 3/26/10 1:46 PM, "Raymond Feng" <[email protected]> wrote: > I went ahead to add the experiment of implementation.jaxrs. It will covers > the case that we deploy the JAX-RS application with the embedded > Tomcat/Jetty without requiring a fully-blown WAR. > > At this point, the implementation.jaxrs will hook the application with > ServletHost. Potentially, we can better align with binding.http. When we > build up the componentType for a JAX-RS application, we could create a > binding.http with wireFormat and operationSelector being configured to > utilize the JAX-RS annotated POJOs for the mapping and dispatching. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Friday, March 26, 2010 12:35 AM > To: <[email protected]> > Subject: Re: JAX-RS as REST binding > >> This approach makes more sense to me as its pretty much the same as >> the initial suggestion ;) I'm not sure that we really need an >> implementation.jaxrs though as there is already implementation.web >> which works for all the other JEE web resources like Servlets, JSPs, >> JSF components etc so why shouldn't JAX-RS resources just be included >> in that? Perhaps we could support both >> implementation.web/implementation.jaxrs if thats going to make >> everyone happy. >> >> ...ant >> >> On Fri, Mar 26, 2010 at 12:34 AM, Raymond Feng <[email protected]> >> wrote: >>> Hi, >>> >>> Since you brought up JMS, I think the JAX-RS application is more like a >>> "MDB" for http. It will be bound to HTTP but it doesn't provide RPC style >>> services for other components to consume directly (without going through >>> a >>> http client). >>> >>> Maybe we should start with an implementation type implementation.jaxrs. >>> The >>> component type won't have any services. When the component is started, we >>> register the application (via a Servlet from the JAX-RS server such as >>> Apache Wink) to the ServletHost. Once it's working, we can explore other >>> possibilities such as: >>> >>> * Allowing SCA annotations (especially @Reference/@Property) to be used >>> with >>> JAX-RS classes so that they can talk to other services (SCA or non-SCA). >>> * Building a RESTful client story so that SCA components can talk to >>> RESTful >>> services. >>> >>> If we like this approach, I can start to produce a prototype based on >>> Apache >>> wink. >>> >>> Thanks, >>> Raymond >>> -------------------------------------------------- >>> From: "Simon Laws" <[email protected]> >>> Sent: Thursday, March 25, 2010 10:12 AM >>> To: <[email protected]> >>> Subject: Re: JAX-RS as REST binding >>> >>>> On Thu, Mar 25, 2010 at 4:42 PM, Raymond Feng <[email protected]> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Do we really want to allow arbitrary SCA services to be exposed to be >>>>> RESTful? REST (resource-oriented) is quite different from RPC >>>>> (operation-oriented). IMO, the component has to be designed following >>>>> the >>>>> RESTful style where we might have a few different options: >>>>> >>>>> * Use an interface that is compatible with the Collection pattern >>>>> * Use JAX-WS annotations to customize the mapping >>>>> >>>>> Thanks, >>>>> Raymond >>>> >>>> Good question. >>>> >>>> In SCA JMS land, for example, you can use an interface that includes >>>> just onMessage() if you want to get close to the binding protocol or >>>> you can use some arbitrary interface and map to it. >>>> >>>> Now REST is slightly different as there are get/put etc. semantics >>>> involved. . I'm not keen on creating more work than absolutely >>>> necessary but maybe a way to answer this is to ask what if we did >>>> allow an arbitrary interface. What rules would that interface have to >>>> obey in order to operate in a RESTfull way? >>>> >>>> The default answer is I guess the rules/configuration that JAX-RS >>>> describes. Which means the binding has to do quite a bit of work to >>>> fill in the blanks in terms of the kind of features that JAXRS would >>>> provide. >>>> >>>> Simon >>> >>>
