resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] Integrating RESTEasy & Spring MVC - Part I

[Solomon D. <sd...@gm...>]

I'm definitely willing to do the work... I've started on it already.  I'm
hoping to get the first cut of it later this week, time permitting.  The
Spring guys are working on Spring 3.0 which will include a REST
implementation on top of their existing annotation infrastructure.  The
Spring community is eagerly waiting Spring 3.0, but the SpringSource guys
keep on moving back their ETA.

A timely RESTful Spring MVC integration from JBoss will definitely turn some
heads ;)

-Solomon

On Mon, Oct 13, 2008 at 2:50 PM, Bill Burke <bb...@re...> wrote:

>
>
> Solomon Duskis wrote:
>
>> I hope that there's enough here to convince you that it's a good idea to
>> explore the possibilities of integration JAX-RS with Spring MVC.  I'm going
>> to send a follow up that describes what I think needs to be done in order to
>> accomplish this integration.
>>
>>
> I'm convinced.  I just need somebody to do the work... (hint hint).
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

Re: [Resteasy-developers] Integrating RESTEasy & Spring MVC - Part I

[Bill B. <bb...@re...>]

Solomon Duskis wrote:
> I hope that there's enough here to convince you that it's a good idea to 
> explore the possibilities of integration JAX-RS with Spring MVC.  I'm 
> going to send a follow up that describes what I think needs to be done 
> in order to accomplish this integration.
> 

I'm convinced.  I just need somebody to do the work... (hint hint).



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

[Resteasy-developers] Integrating RESTEasy & Spring MVC - Part I

[Solomon D. <sd...@gm...>]

I'm thinking through what's needed in order to integrate REST Easy and
Spring MVC.  Before I explain the integration, I think I need to explain how
Spring MVC work.  This turned into a pretty lengthy article, but I think
that the goals of the integration are pretty interesting...  Basically, I
think this could extend both the abilities of Spring MVC and JAX-RS's
capabilities.  If done properly, the integration will allow JAX-RS to act as
an MVC controller or work along side other complementary MVC technologies.
When it comes to the implementation, I'll be pretty careful to separate out
the Spring MVC specific code and the code required to make RESTEay IoC and
MVC accessible.  James Strachan is taking a look at a Guice/JAX-RS
integration, and I'll keep his ideas in mind as well:
http://macstrac.blogspot.com/2008/10/adding-support-for-postconstruct.html

*MVC*

You probably know what MVC is, but I'll rehash it anyway.

Model - Sevice Layer and below, it also includes the Domain Layer.
Controller - an object/method that's responsible for the logic that the UI
needs - validation, binding, error handling, relaying messages between the
Model and View
View - show the data

Web MVC has the following specifics:
- URL determines Controller
- The Controller handles setting HTTP headers (cookies, caching & etc)
- Controller does it's work and passes back data and some way to determine a
View
  -- the view determination can be based a string representing a logical
name (Struts and Spring MVC do this)
  -- the view can be determined based on the data (similar to JAX-RS or
DWR).

Web MVC tends to have a DispatchingServlet that performs the handoff to the
Controller.  There needs to be some storage and management of URLMappings,
Controllers and Views.  Each MVC has their own proprietary management
system, but can generally work with a generic IoC Container.

  (One of the benefits of using IoC Containers is that the Model and
Controllers are managed by the same construct, so you don't have to perform
service lookups.)

Taking a step back, JAX-RS is already a Web MVC implementation!

*Spring MVC
*
Spring MVC has a few decoupled parts to it :

1) A couple APIs for creating Controllers: the old way uses a class
hierarchy, and the new way uses annotations that are similar to JAX-RS's
annotations.

2) A mechanism for rendering Views: you can choose from a plethora of view
technologies: JSP/JSTL, JSF, Tiles, Velocity, FreeMarker and XSLT.
Theoretically, you can create a View that knows how to transform objects via
JAXB; there are JSon-Lib and Jettison based Views.

3) An object that encapsulates both the data and the logical view:
ModelAndView.  Model is a Map of data, and view is the logical name of the
View, or the View object itself.

4) A mechanism for URL Mapping - HandlerMapping: given a URL, it helps you
find a Spring managed bean.  You have different strategies you can use, or
you can build your own:
  A) Use the URLS configured in @Controller objects,
  B) Map a URL to the name the controller (/customer maps to
CustomerController)
  C) Explicitely configure URL regex to controller via key/value pairs
  D) Roll out your own custom mapping (for example, you can lookup a
"controller"/ResourceInvoker in the RESTEasy Dispatcher)

Using approach C has the side affect of allowing you to add on functionality
via explicitly configuring Interceptors, although I believe that the other
implementations can work with interceptors

5) A mechanism for handling the bean found by the HandlerMapping -
HandlerAdapter: the bean found in #4 could be a traditional Spring MVC
controller, an annotated Spring MVC controller, a Servlet, a Struts Action
or a JAX-RS resource.  HandlerAdapters are adapters that know what kinds of
beans they handle, and how to pass the HTTP request/response to those
beans.  Each Handler adapter returns a ModelAndView which is then rendered
by #2

6) A mechanism for binding web data (specifically incoming request/form
parameters) into a DTO.  Basically, it has a convention that maps request
parameters to potentially nested values.  For example, foo.bar.baz would
translate into myDto.getFoo().getBar().setBaz().  It also allows for some
binding from String to Object conversion similar to @Providers.  In the new
@Controller mechansim, you can list out the parameters in the method,
similar to JAX-RS, or you can have a DTO object that encapsulate those
parameters

7) Validation

8) Objects from the Session

*What JAX-RS has the Spring MVC doesn't*

1) JAX-RS has a much more robust set of web annotations (CookieParam,
MatrixParam, ProduceMime, ConsumeMime and etc)

2) Deep JAXB integration.  It's possible to use JAXB (or
Jettison/XStream/Jibx) to render results in Spring, but you'd have to write
and integrate it yourself.  You can't currently bind a JSon POST to a POJO
using Spring MVC.

3) Different REST Representation depending on configuration and request
headers.

I'm sure I'm missing some other JAX-RS benefits, but these are the ones that
stand out off the top of my head.

*Goals of JAX-RS and Spring MVC*

1) JAX-RS and other "controllers" working side by side.  Different
controller implementation APIs have different strengths and weaknesses.
Currently, JAX-RS doesn't work with HTTPSession, but Spring MVC does.  Sure
it would cause a bit of a management headache to have a few controller
development models, but it's a headache that exists right now for people
that need both HTML and JSon/XML websites.  I've used Spring MVC for HTML
representation, and DWR for Data/JSon transfers.  Theoretically, you can do
this right now, by deploying the RESTEasy servlet + the Spring MVC Servlet,
but a deeper integration would expose more functionality.

2) JAX-RS as a Controller:

  A) Validation integration into JAX-RS, with a common way to expose
validation errors...  I'm not quite sure how this would work, and there may
be better integrations with the Validation JSR, but this would be possible.

  B) Binding a set of parameters as into a JAXB Object/POJO?  Basically,
Spring MVC provides the means to have an object that encapsulates a set of
request parameters.  Is there a way to use JAX-RS/RESTEasy that way?

3) Providers as Views: Using the JAX-RS Producers to implement Spring
Views... This would allow Spring Controllers to render results with the
RESTEasy Producer infrastructure.

4) JAX RS Resources with complex HTML Views:  Clever integration would allow
results from a JAX-RS Resource to be rendered with a complex HTML
representation provided by the View technologies that Spring MV supports:
jsp/jsf/freemarker/velocity Views can also be used for
@Produces("text/html").   This could also be used for
Produces("application/xml") where you don't necessarily want to use an
object based binding technology.

*Conclusion*

I hope that there's enough here to convince you that it's a good idea to
explore the possibilities of integration JAX-RS with Spring MVC.  I'm going
to send a follow up that describes what I think needs to be done in order to
accomplish this integration.

-Solomon Duskis

Re: [Resteasy-developers] RESTEasy client changes

[Solomon D. <sd...@gm...>]

I'm not quite sure what the API should look like.  Here's where I see
needing interception points

1) before request: add some information to the request (add/modify a
parameter, cookie)
2) after the raw request before JAXB transformation: modifying the raw
results and headers
3) around the request + JAXB transformation: for example, caching.

What should the interface/annotations of each of those scenarios look like?

-Solomon

On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re...> wrote:

>
>
> Solomon Duskis wrote:
>
>> I refactored the ProxyFactory code a bit, and attached it as a .zip file
>> to this email.
>>
>> Here's a summary of what I did:
>>
>> 1) ClientInvoker:
>>  A) I refactored the invoke method into smaller, overridable methods:
>>     - generate base URI
>>     - populate parameters
>>     - retrieve results
>>    B) I moved the creation of Get/Put/Post/Delete HttpMethodBase into a
>> factory (HttpMethodBaseFactory).  I got rid of GetInvoker/PutInvoker... and
>> replaced them with a call to
>> HttpMethodBaseFactoy.createDefaultFactory(String method) which gets called
>> as part of the "retrieve results" step.  I did this so that the methods in
>> 1A can be overridden in an without interfering with the HttpMethodBase
>> object creation.
>>
>>  The combination of those two changes should allow clever subclassing,
>> like adding extra parameters or caching a GET call.  An interface would
>> allow some fancy decorations: CachingClient ->
>> ProprietaryParameterAddingClient -> BaseClientInvokerl; however, I didn't
>> want to build that just yet without vetting the general idea with the group.
>>  2) ProxyFactory;
>>  A) I made it into an abstract class (I didn't bother with an interface,
>> so that I can keep the existing static methods and still keep the
>> ProxyFactory class)
>>    B) I added an abstract method createFactory(Class<T>) along with a
>> DefaultProxyFactory implementation that that has the original ProxyFactory
>> functionality.  A user will need to override the
>> ProxyFactory.createClientInvoker() in order to create the clever subclass of
>> ClientInvoker
>>
>>
>
> This wasn't the approach I was thinking of.  Think Servlet Filters but on
> the client.  Each filter (interceptor) could add whatever headers/data it
> wanted to the request (i.e. a custom security interceptor).  Each filter
> could process the response in a special way (for instance, the
> client-caching interceptor looks for Cache-Control headers in the response
> and caches accordingly).
>
>
>
>> As far as the caching client goes: I'm not quite sure which existing
>> caching solution best fits a RESTful request.
>>
>
> Read up on Cache-Control header.  Basically the server passes a response
> header that states the cache policy.  Its a pretty rich protocol.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

Re: [Resteasy-developers] RESTEasy client changes

[Ryan J. M. <ry...@da...>]

Hey Bill,

I have been thinking about this and following this thread. First off,  
I would not like to see a cache solution work with a single API. For  
some folks, JBoss TreeCache may not be an option and some larger  
clients may want to leverage existing caching solutions. I can  
envision the scenario where an application could utilize a clustered  
HTTP cache but also require something small and sweet. I'd like to be  
able to be flexible while being able to accommodate HTTP caching  
properly. If we would have to implement our own logic to accommodate a  
per-resource expiry, I don't see it as necessarily a bad thing. It's  
just more work ;). My current thinking is that we create some type of  
pluggable SPI so that we can take advantage of any caching system.  
With that said, I'm a bit more of a fan of the "layer on top" of an  
existing caching API.

I guess the question is, do people agree on the "layer on top" approach?

Ryan-



On Oct 10, 2008, at 9:49 AM, Bill Burke wrote:

> I know JBoss Cache allows you to define domains based on node-path.   
> So
> it might work.  I've pinged Manik on it.
>
> Cache-Control is weird though.  You may keep something cached for as
> long as you like, but you have to validate it with the server.
>
> It would be really cool if I could find somebody to look into this
> (and/or the Spring thing too).  I've been meaning to do it, but I get
> stuck writing articles and fixing bugs.  TCK work is starting next  
> week
> too :(.
>
> Solomon Duskis wrote:
>> Bill,
>>
>> Yeah, I understand the protocol well enough...  The problem is  
>> chosing
>> an cache implementation technology.
>>
>> RESTful caching requires per-resource value for "max time to live"
>> because each URL can have a different value.  You'll definitely  
>> need a
>> wrapper object to store ETag info; however, it would be nice to use  
>> the
>> caching technology's expiration/eviction settings rather than  
>> having to
>> build that yourself.
>>
>> All of the caching technologies I've seen, except for memcached,  
>> have a
>> per cache setting for "max time to live" (determined by an XML  
>> file, or
>> programmatically).  Memcached allows you to set a timeout per cached
>> instance rather than per cache, but you probably rule out memcached
>> because a purely distributed cache system seems like a totally wrong
>> solution for a RESTful client.
>>
>> Unless I'm mistaken, you'll have to either modify a caching  
>> technology
>> to allow a per instance timeout (which I assume you can do with your
>> pull with the JBoss caching team, Bill), or to write a layer on top  
>> of
>> an existing solution that manually checks max-age/Expires values in
>> order to do expiration.
>>
>> -Solomon
>>
>> On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re...
>> <mailto:bb...@re...>> wrote:
>>
>>    <snip>
>>
>>
>>
>>        As far as the caching client goes: I'm not quite sure which
>>        existing caching solution best fits a RESTful request.
>>
>>
>>    Read up on Cache-Control header.  Basically the server passes a
>>    response header that states the cache policy.  Its a pretty rich
>>    protocol.
>>
>>
>>    --
>>    Bill Burke
>>    JBoss, a division of Red Hat
>>    http://bill.burkecentral.com
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] RESTEasy client changes

[Bill B. <bb...@re...>]

I don't think you need a clustered solution for caching.  Whether on the 
client or on the server.  If we follow Cache-Control semantics, we 
shouldn't need this complication.  With that said, using JBoss Cache 
local-only (Manik has done some serious work here) or something like 
EhCache should be fine.

IMO, I don't think anybody will care about a pluggable SPI if we follow 
strict Cache-Control semantics.  Then again, I don't care how its 
implemented as long as a contributor does the work :)

Ryan J. McDonough wrote:
> Hey Bill,
> 
> I have been thinking about this and following this thread. First off, I 
> would not like to see a cache solution work with a single API. For some 
> folks, JBoss TreeCache may not be an option and some larger clients may 
> want to leverage existing caching solutions. I can envision the scenario 
> where an application could utilize a clustered HTTP cache but also 
> require something small and sweet. I'd like to be able to be flexible 
> while being able to accommodate HTTP caching properly. If we would have 
> to implement our own logic to accommodate a per-resource expiry, I don't 
> see it as necessarily a bad thing. It's just more work ;). My current 
> thinking is that we create some type of pluggable SPI so that we can 
> take advantage of any caching system. With that said, I'm a bit more of 
> a fan of the "layer on top" of an existing caching API.
> 
> I guess the question is, do people agree on the "layer on top" approach?
> 
> Ryan-
> 
> 
> 
> On Oct 10, 2008, at 9:49 AM, Bill Burke wrote:
> 
>> I know JBoss Cache allows you to define domains based on node-path.  So
>> it might work.  I've pinged Manik on it.
>>
>> Cache-Control is weird though.  You may keep something cached for as
>> long as you like, but you have to validate it with the server.
>>
>> It would be really cool if I could find somebody to look into this
>> (and/or the Spring thing too).  I've been meaning to do it, but I get
>> stuck writing articles and fixing bugs.  TCK work is starting next week
>> too :(.
>>
>> Solomon Duskis wrote:
>>> Bill,
>>>
>>> Yeah, I understand the protocol well enough...  The problem is chosing
>>> an cache implementation technology.
>>>
>>> RESTful caching requires per-resource value for "max time to live"
>>> because each URL can have a different value.  You'll definitely need a
>>> wrapper object to store ETag info; however, it would be nice to use the
>>> caching technology's expiration/eviction settings rather than having to
>>> build that yourself.
>>>
>>> All of the caching technologies I've seen, except for memcached, have a
>>> per cache setting for "max time to live" (determined by an XML file, or
>>> programmatically).  Memcached allows you to set a timeout per cached
>>> instance rather than per cache, but you probably rule out memcached
>>> because a purely distributed cache system seems like a totally wrong
>>> solution for a RESTful client.
>>>
>>> Unless I'm mistaken, you'll have to either modify a caching technology
>>> to allow a per instance timeout (which I assume you can do with your
>>> pull with the JBoss caching team, Bill), or to write a layer on top of
>>> an existing solution that manually checks max-age/Expires values in
>>> order to do expiration.
>>>
>>> -Solomon
>>>
>>> On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re...
>>> <mailto:bb...@re...>> wrote:
>>>
>>>    <snip>
>>>
>>>
>>>
>>>        As far as the caching client goes: I'm not quite sure which
>>>        existing caching solution best fits a RESTful request.
>>>
>>>
>>>    Read up on Cache-Control header.  Basically the server passes a
>>>    response header that states the cache policy.  Its a pretty rich
>>>    protocol.
>>>
>>>
>>>    --
>>>    Bill Burke
>>>    JBoss, a division of Red Hat
>>>    http://bill.burkecentral.com
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the 
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> 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

Re: [Resteasy-developers] RESTEasy client changes

[Bill B. <bb...@re...>]

I know JBoss Cache allows you to define domains based on node-path.  So 
it might work.  I've pinged Manik on it.

Cache-Control is weird though.  You may keep something cached for as 
long as you like, but you have to validate it with the server.

It would be really cool if I could find somebody to look into this 
(and/or the Spring thing too).  I've been meaning to do it, but I get 
stuck writing articles and fixing bugs.  TCK work is starting next week 
too :(.

Solomon Duskis wrote:
> Bill,
> 
> Yeah, I understand the protocol well enough...  The problem is chosing 
> an cache implementation technology.
> 
> RESTful caching requires per-resource value for "max time to live" 
> because each URL can have a different value.  You'll definitely need a 
> wrapper object to store ETag info; however, it would be nice to use the 
> caching technology's expiration/eviction settings rather than having to 
> build that yourself.
> 
> All of the caching technologies I've seen, except for memcached, have a 
> per cache setting for "max time to live" (determined by an XML file, or 
> programmatically).  Memcached allows you to set a timeout per cached 
> instance rather than per cache, but you probably rule out memcached 
> because a purely distributed cache system seems like a totally wrong 
> solution for a RESTful client. 
> 
> Unless I'm mistaken, you'll have to either modify a caching technology 
> to allow a per instance timeout (which I assume you can do with your 
> pull with the JBoss caching team, Bill), or to write a layer on top of 
> an existing solution that manually checks max-age/Expires values in 
> order to do expiration. 
> 
> -Solomon
> 
> On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re... 
> <mailto:bb...@re...>> wrote:
> 
>     <snip>
> 
>  
> 
>         As far as the caching client goes: I'm not quite sure which
>         existing caching solution best fits a RESTful request.
> 
> 
>     Read up on Cache-Control header.  Basically the server passes a
>     response header that states the cache policy.  Its a pretty rich
>     protocol.
> 
> 
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Re: [Resteasy-developers] RESTEasy client changes

[Solomon D. <sd...@gm...>]

Bill,

Yeah, I understand the protocol well enough...  The problem is chosing an
cache implementation technology.

RESTful caching requires per-resource value for "max time to live" because
each URL can have a different value.  You'll definitely need a wrapper
object to store ETag info; however, it would be nice to use the caching
technology's expiration/eviction settings rather than having to build that
yourself.

All of the caching technologies I've seen, except for memcached, have a per
cache setting for "max time to live" (determined by an XML file, or
programmatically).  Memcached allows you to set a timeout per cached
instance rather than per cache, but you probably rule out memcached because
a purely distributed cache system seems like a totally wrong solution for a
RESTful client.

Unless I'm mistaken, you'll have to either modify a caching technology to
allow a per instance timeout (which I assume you can do with your pull with
the JBoss caching team, Bill), or to write a layer on top of an existing
solution that manually checks max-age/Expires values in order to do
expiration.

-Solomon

On Wed, Oct 8, 2008 at 4:33 PM, Bill Burke <bb...@re...> wrote:

> <snip>



> As far as the caching client goes: I'm not quite sure which existing
>> caching solution best fits a RESTful request.
>>
>
> Read up on Cache-Control header.  Basically the server passes a response
> header that states the cache policy.  Its a pretty rich protocol.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

Re: [Resteasy-developers] Generics Support

[Bill B. <bb...@re...>]

I'm not even sure you can do that with JAXB, that is, have a Generic as 
a @XmlRootElement that has an attribute that returns an arbitrary JAXB 
annotated object.  I would try implementing what you're doing with 
manual JAXB to see if it actually works.

The eating of the error is a problem though.  (I thought I had cleaned 
that all up :(  )

BTW:

Here's the test case for GenericEntity:

http://resteasy.svn.sourceforge.net/viewvc/resteasy/tags/RESTEASY_JAXRS_1_0_BETA_8/resteasy-jaxrs/src/test/java/org/jboss/resteasy/test/finegrain/resource/GenericEntityTest.java?revision=347&view=markup

Bill

Mike Chack (mchack) wrote:
> Thanks for the response. Figured you would have had a solution. I gave
> it a try and I get a 500 response with no visible exception thrown. Not
> sure if I am doing something dumb here or abusing the use of
> GenericEntity
> 
> @GET
> @Produces("text/xml")
> @RolesAllowed({"admin","super","user","mainuser"}) 
> @Path("/test")
> public Response getSessionXmlTest() 
> {
> 	Session session = new Session(SecurityFilter.getCurrentToken());
> 	
> 	RestResponse status = new RestResponse("Session creation ok -
> expires at - " + SecurityFilter.getExpirationTime());
> 	
> 	RestResponseWrapper1<Session> wrapper = new
> RestResponseWrapper1<Session>(status,session);
> 	
> 	GenericEntity<RestResponseWrapper1<Session>> ge = new
> GenericEntity<RestResponseWrapper1<Session>>(wrapper){};
> 		   
> 	Response response =
> Response.ok(ge,MediaType.TEXT_XML_TYPE).build();
> 		   return response;
> }
> 
> @XmlRootElement(name = "ctbuapi")
> public class RestResponseWrapper1<T> {
> 	
> 	private T result;
> 	
> 	RestResponse response = new RestResponse();
> 
> 	
> 	public RestResponseWrapper1()
> 	{
> 		
> 	}
> 	
> 	public RestResponseWrapper1(RestResponse response,T result)
> 	{
> 		this.response = response;
> 		this.result = result;
> 	}
> 	
> 	public RestResponse getResponse() {
> 		return response;
> 	}
> 
> 	public void setResponse(RestResponse response) {
> 		this.response = response;
> 	}
> 	
> 	public T getResult() {
> 		return result;
> 	}
> 
> 	public void setResult(T session) {
> 		this.result = session;
> 	}
> 
> 
> }
> 
> Mike Chack 
> 
> 
> -----Original Message-----
> From: Bill Burke [mailto:bb...@re...] 
> Sent: Thursday, October 09, 2008 7:47 AM
> To: Mike Chack (mchack)
> Cc: res...@li...
> Subject: Re: [Resteasy-developers] Generics Support
> 
> See GenericEntity.
> 
> Mike Chack (mchack) wrote:
>> I was wondering if the following pattern is supported, don't think so 
>> but I may be missing something.
>>
>>  
>>
>> I would like to have a generic class wrap all my REST responses.
>>
>>  
>>
>> @GET
>>
>> @Path(/somepath)
>>
>> public GenericWrapper someMethod()
>>
>> {
>>
>>       ResponseObject response = New ResponseObject();
>>
>>       return new GenericWrapper<response>(response);
>>
>>  
>>
>> }
>>
>>  
>>
>> The ResponseObject extends BasicResponse and is also annoted with
> JAX-B 
>> @XmlRootEntity.
>>
>>  
>>
>>  
>>
>> @XmlRootEntity
>>
>> public class GenericWrapper<T extends BasicResponse>
>>
>> {
>>
>>    
>>
>>     String  commondata;
>>
>>     String othercommondata;
>>
>>     String resultcode;
>>
>>     ................
>>
>>  
>>
>>     T response;
>>
>>  
>>
>>     public GenericWrapper(T response)
>>
>>     {
>>
>>         this.response = response;
>>
>>     }
>>
>> }
>>
>>  
>>
>> This way it simplifes the number of concrete classes needed for 
>> different response types. I don't think this works. Is there another 
>> pattern for this or is it reasonable for the framework to  examine the
> 
>> generics definition and search out the classes that extend
> BasicResponse 
>> that have JAX-B annotations so proper marshalling can occur?
>>
>>  
>>
>> thanks
>>
>> *Mike Chack*
>> *O: +1 408.526.4639*
>> *M: +1 408.504.6594*
>> *mc...@ci...*
>>
>>  
>>
>>
>>
> ------------------------------------------------------------------------
>>
> ------------------------------------------------------------------------
> -
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>>
> ------------------------------------------------------------------------
>> _______________________________________________
>> 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

Re: [Resteasy-developers] Generics Support

[Mike C. (mchack) <mc...@ci...>]

Thanks for the response. Figured you would have had a solution. I gave
it a try and I get a 500 response with no visible exception thrown. Not
sure if I am doing something dumb here or abusing the use of
GenericEntity

@GET
@Produces("text/xml")
@RolesAllowed({"admin","super","user","mainuser"}) 
@Path("/test")
public Response getSessionXmlTest() 
{
	Session session = new Session(SecurityFilter.getCurrentToken());
	
	RestResponse status = new RestResponse("Session creation ok -
expires at - " + SecurityFilter.getExpirationTime());
	
	RestResponseWrapper1<Session> wrapper = new
RestResponseWrapper1<Session>(status,session);
	
	GenericEntity<RestResponseWrapper1<Session>> ge = new
GenericEntity<RestResponseWrapper1<Session>>(wrapper){};
		   
	Response response =
Response.ok(ge,MediaType.TEXT_XML_TYPE).build();
		   return response;
}

@XmlRootElement(name = "ctbuapi")
public class RestResponseWrapper1<T> {
	
	private T result;
	
	RestResponse response = new RestResponse();

	
	public RestResponseWrapper1()
	{
		
	}
	
	public RestResponseWrapper1(RestResponse response,T result)
	{
		this.response = response;
		this.result = result;
	}
	
	public RestResponse getResponse() {
		return response;
	}

	public void setResponse(RestResponse response) {
		this.response = response;
	}
	
	public T getResult() {
		return result;
	}

	public void setResult(T session) {
		this.result = session;
	}


}

Mike Chack 


-----Original Message-----
From: Bill Burke [mailto:bb...@re...] 
Sent: Thursday, October 09, 2008 7:47 AM
To: Mike Chack (mchack)
Cc: res...@li...
Subject: Re: [Resteasy-developers] Generics Support

See GenericEntity.

Mike Chack (mchack) wrote:
> I was wondering if the following pattern is supported, don't think so 
> but I may be missing something.
> 
>  
> 
> I would like to have a generic class wrap all my REST responses.
> 
>  
> 
> @GET
> 
> @Path(/somepath)
> 
> public GenericWrapper someMethod()
> 
> {
> 
>       ResponseObject response = New ResponseObject();
> 
>       return new GenericWrapper<response>(response);
> 
>  
> 
> }
> 
>  
> 
> The ResponseObject extends BasicResponse and is also annoted with
JAX-B 
> @XmlRootEntity.
> 
>  
> 
>  
> 
> @XmlRootEntity
> 
> public class GenericWrapper<T extends BasicResponse>
> 
> {
> 
>    
> 
>     String  commondata;
> 
>     String othercommondata;
> 
>     String resultcode;
> 
>     ................
> 
>  
> 
>     T response;
> 
>  
> 
>     public GenericWrapper(T response)
> 
>     {
> 
>         this.response = response;
> 
>     }
> 
> }
> 
>  
> 
> This way it simplifes the number of concrete classes needed for 
> different response types. I don't think this works. Is there another 
> pattern for this or is it reasonable for the framework to  examine the

> generics definition and search out the classes that extend
BasicResponse 
> that have JAX-B annotations so proper marshalling can occur?
> 
>  
> 
> thanks
> 
> *Mike Chack*
> *O: +1 408.526.4639*
> *M: +1 408.504.6594*
> *mc...@ci...*
> 
>  
> 
> 
>
------------------------------------------------------------------------
> 
>
------------------------------------------------------------------------
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Re: [Resteasy-developers] Generics Support

[Mike C. (mchack) <mc...@ci...>]

Thanks for the response. Figured you would have had a solution. I gave
it a try and I get a 500 response with no visible exception thrown. Not
sure if I am doing something dumb here or abusing the use of
GenericEntity

@GET
@Produces("text/xml")
@RolesAllowed({"admin","super","user","mainuser"}) 
@Path("/test")
public Response getSessionXmlTest() 
{
	Session session = new Session(SecurityFilter.getCurrentToken());
	
	RestResponse status = new RestResponse("Session creation ok -
expires at - " + SecurityFilter.getExpirationTime());
	
	RestResponseWrapper1<Session> wrapper = new
RestResponseWrapper1<Session>(status,session);
	
	GenericEntity<RestResponseWrapper1<Session>> ge = new
GenericEntity<RestResponseWrapper1<Session>>(wrapper){};
		   
	Response response =
Response.ok(ge,MediaType.TEXT_XML_TYPE).build();
		   return response;
}

@XmlRootElement(name = "ctbuapi")
public class RestResponseWrapper1<T> {
	
	private T result;
	
	RestResponse response = new RestResponse();

	
	public RestResponseWrapper1()
	{
		
	}
	
	public RestResponseWrapper1(RestResponse response,T result)
	{
		this.response = response;
		this.result = result;
	}
	
	public RestResponse getResponse() {
		return response;
	}

	public void setResponse(RestResponse response) {
		this.response = response;
	}
	
	public T getResult() {
		return result;
	}

	public void setResult(T session) {
		this.result = session;
	}


}

Mike Chack 


-----Original Message-----
From: Bill Burke [mailto:bb...@re...] 
Sent: Thursday, October 09, 2008 7:47 AM
To: Mike Chack (mchack)
Cc: res...@li...
Subject: Re: [Resteasy-developers] Generics Support

See GenericEntity.

Mike Chack (mchack) wrote:
> I was wondering if the following pattern is supported, don't think so 
> but I may be missing something.
> 
>  
> 
> I would like to have a generic class wrap all my REST responses.
> 
>  
> 
> @GET
> 
> @Path(/somepath)
> 
> public GenericWrapper someMethod()
> 
> {
> 
>       ResponseObject response = New ResponseObject();
> 
>       return new GenericWrapper<response>(response);
> 
>  
> 
> }
> 
>  
> 
> The ResponseObject extends BasicResponse and is also annoted with
JAX-B 
> @XmlRootEntity.
> 
>  
> 
>  
> 
> @XmlRootEntity
> 
> public class GenericWrapper<T extends BasicResponse>
> 
> {
> 
>    
> 
>     String  commondata;
> 
>     String othercommondata;
> 
>     String resultcode;
> 
>     ................
> 
>  
> 
>     T response;
> 
>  
> 
>     public GenericWrapper(T response)
> 
>     {
> 
>         this.response = response;
> 
>     }
> 
> }
> 
>  
> 
> This way it simplifes the number of concrete classes needed for 
> different response types. I don't think this works. Is there another 
> pattern for this or is it reasonable for the framework to  examine the

> generics definition and search out the classes that extend
BasicResponse 
> that have JAX-B annotations so proper marshalling can occur?
> 
>  
> 
> thanks
> 
> *Mike Chack*
> *O: +1 408.526.4639*
> *M: +1 408.504.6594*
> *mc...@ci...*
> 
>  
> 
> 
>
------------------------------------------------------------------------
> 
>
------------------------------------------------------------------------
-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
>
------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Re: [Resteasy-developers] Spring eye for the RESTEasy guy - part 1

[Bill B. <bb...@re...>]

I was thinking about your post here as well as looking at your blog that 
described various Spring+JAX-RS integration.

I think it would be interesting to expand on your ideas.  Want to help?

I was thinking first step on developing a set of classes that allowed 
you to define a set of JAX-RS Resources and Providers.  Basically what 
CXF allows you to do and group providers, resources, and configuration 
options into individual sets.

i.e.

* A set of providers that apply to a specific set of resources.
* A set of providers that apply to only one resource (allows you to 
override marshalling per resource.
* A set of config that applies to a provider and/or a resource
* Etc...

Creating the classes for this is pretty easy and straightforward.  What 
I don't know how to do is define my own XML namespace/schema and plug it 
into Spring (or Seam for that matter as I know they have something similar).

As a first step, would you be interested in defining/creating that 
integration?  Then we can look at refactoring Resteasy to provide that 
kind of fine-grain scoping.

Bill Burke wrote:
> 
> Solomon Duskis wrote:
>> Re ResourceExposingService - I guess it was a bad name... I basically 
>> meant ResteasyRegistration.  I do hope this makes it into the RESTEasy core.
>>
>> Re IoC container dependency: What I really want is a way to use the 
>> Spring MVC framework right along side JAX-RS/RESTEasy.  It will allow me 
>> to configure which requests go to Spring MVC Controllers/Struts 
>> Actions/JAX-RS Resources and how to render Views/Producers with 
>> Velocity/Freemarker/Tiles/JSP.  In order to get that to work properly, 
>> I'll need to store the Registry et al in the Spring Application context 
>> instead of the ServletContext.
>>
> 
> Why do you need access to the Registry?  And if you really do, can't it 
> be manually registered?
> 
>> Perhaps I'll just vet some ideas in this group as to how I could use 
>> RESTEasy towards my ends.  The means I use to achieve my ends may may be 
>> helpful for other MVC and IoC integrations such as Struts2/Guice... I 
>> know RESTEasy already works with Seam ;).
>>
> 
> Yes, please brainstorm.  I'm Spring ignorant beyond basic IoC so any 
> insight would be invaluable.
> 
> 

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

Re: [Resteasy-developers] Having problems after upgrading to beta-8 version

[Todd O E. <tod...@pn...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That worked.&nbsp; Thanks!<br>
<br>
Bill Burke wrote:
<blockquote cite="mid:48E...@re..." type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 6.5.7653.38">
  <title>Re: [Resteasy-developers] Having problems after upgrading to
beta-8 version</title>
<!-- Converted from text/plain format -->
  <p><font size="2">To get around the problem, set your content-type in
your Response.<br>
  <br>
I'll log a jira bug and set the content-type if there is not one sent in<br>
the response.<br>
  <br>
Todd O Elsethagen wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I'm having a problem when using the Response class.&nbsp; The following
code<br>
&gt; worked in 1.0-beta-5 version but no longer works after upgrading to<br>
&gt; 1.0-beta-8.&nbsp; The only change i made from the beta-5 version to
beta-8<br>
&gt; version is changing the @ProduceMime to @Produces.&nbsp; The beta-5
version<br>
&gt; would create an xml representation of the Protocol class, which
contains<br>
&gt; jaxb annotations.&nbsp; However, the beta-8 version no longer creates
the xml<br>
&gt; representation, it just returns a simple string that looks
something<br>
&gt; like this, "Protocol@1253dfb".&nbsp; What do i need to change to get
this to<br>
&gt; work in the beta-8 version?<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Todd<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; @GET<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; @Path("protocol/{id}")<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; @Produces("application/xml")<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; public Response getProtocol(@PathParam("id") Long id);<br>
&gt;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; public Response getProtocol(Long id) {<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Response response;<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Protocol entity = protocolDAO.findById(id);<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (entity != null) {<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response = Response.ok(entity).build();<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else {<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response = Response.serverError().build();&nbsp;&nbsp;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return response;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;
-------------------------------------------------------------------------<br>
&gt; This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge<br>
&gt; Build the coolest Linux based applications with Moblin SDK &amp;
win great prizes<br>
&gt; Grand prize is a trip for two to an Open Source event anywhere in
the world<br>
&gt; <a moz-do-not-send="true"
 href="http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/">http://moblin-contest.org/redirect.php?banner_id=100&amp;url=/</a><br>
&gt; _______________________________________________<br>
&gt; Resteasy-developers mailing list<br>
&gt; <a class="moz-txt-link-abbreviated" href="mailto:Res...@li...">Res...@li...</a><br>
&gt; <a moz-do-not-send="true"
 href="https://lists.sourceforge.net/lists/listinfo/resteasy-developers">https://lists.sourceforge.net/lists/listinfo/resteasy-developers</a><br>
  <br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
  <a moz-do-not-send="true" href="http://bill.burkecentral.com">http://bill.burkecentral.com</a><br>
  </font>
  </p>
</blockquote>
<br>
</body>
</html>

Re: [Resteasy-developers] Having problems after upgrading to beta-8 version

[Bill B. <bb...@re...>]

To get around the problem, set your content-type in your Response.

I'll log a jira bug and set the content-type if there is not one sent in 
the response.

Todd O Elsethagen wrote:
> Hi,
> 
> I'm having a problem when using the Response class.  The following code 
> worked in 1.0-beta-5 version but no longer works after upgrading to 
> 1.0-beta-8.  The only change i made from the beta-5 version to beta-8 
> version is changing the @ProduceMime to @Produces.  The beta-5 version 
> would create an xml representation of the Protocol class, which contains 
> jaxb annotations.  However, the beta-8 version no longer creates the xml 
> representation, it just returns a simple string that looks something 
> like this, "Protocol@1253dfb".  What do i need to change to get this to 
> work in the beta-8 version?
> 
> Thanks,
> Todd
> 
> 
>     @GET
>     @Path("protocol/{id}")
>     @Produces("application/xml")
>     public Response getProtocol(@PathParam("id") Long id);
> 
> 
>     public Response getProtocol(Long id) {
> 
>         Response response;
> 
>         Protocol entity = protocolDAO.findById(id);
>        
>         if (entity != null) {
>             response = Response.ok(entity).build();
>         }
>         else {
>             response = Response.serverError().build();   
>         }
> 
>         return response;
>     }
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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

[Resteasy-developers] Having problems after upgrading to beta-8 version

[Todd O E. <tod...@pn...>]

Hi,

I'm having a problem when using the Response class.  The following code 
worked in 1.0-beta-5 version but no longer works after upgrading to 
1.0-beta-8.  The only change i made from the beta-5 version to beta-8 
version is changing the @ProduceMime to @Produces.  The beta-5 version 
would create an xml representation of the Protocol class, which contains 
jaxb annotations.  However, the beta-8 version no longer creates the xml 
representation, it just returns a simple string that looks something 
like this, "Protocol@1253dfb".  What do i need to change to get this to 
work in the beta-8 version?

Thanks,
Todd


    @GET
    @Path("protocol/{id}")
    @Produces("application/xml")
    public Response getProtocol(@PathParam("id") Long id);


    public Response getProtocol(Long id) {

        Response response;

        Protocol entity = protocolDAO.findById(id);
       
        if (entity != null) {
            response = Response.ok(entity).build();
        }
        else {
            response = Response.serverError().build();   
        }

        return response;
    }

Re: [Resteasy-developers] Generics Support

[Bill B. <bb...@re...>]

See GenericEntity.

Mike Chack (mchack) wrote:
> I was wondering if the following pattern is supported, don’t think so 
> but I may be missing something.
> 
>  
> 
> I would like to have a generic class wrap all my REST responses.
> 
>  
> 
> @GET
> 
> @Path(/somepath)
> 
> public GenericWrapper someMethod()
> 
> {
> 
>       ResponseObject response = New ResponseObject();
> 
>       return new GenericWrapper<response>(response);
> 
>  
> 
> }
> 
>  
> 
> The ResponseObject extends BasicResponse and is also annoted with JAX-B 
> @XmlRootEntity.
> 
>  
> 
>  
> 
> @XmlRootEntity
> 
> public class GenericWrapper<T extends BasicResponse>
> 
> {
> 
>    
> 
>     String  commondata;
> 
>     String othercommondata;
> 
>     String resultcode;
> 
>     …………….
> 
>  
> 
>     T response;
> 
>  
> 
>     public GenericWrapper(T response)
> 
>     {
> 
>         this.response = response;
> 
>     }
> 
> }
> 
>  
> 
> This way it simplifes the number of concrete classes needed for 
> different response types. I don’t think this works. Is there another 
> pattern for this or is it reasonable for the framework to  examine the 
> generics definition and search out the classes that extend BasicResponse 
> that have JAX-B annotations so proper marshalling can occur?
> 
>  
> 
> thanks
> 
> *Mike Chack*
> *O: +1 408.526.4639*
> *M: +1 408.504.6594*
> *mc...@ci...*
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

[Resteasy-developers] Generics Support

[Mike C. (mchack) <mc...@ci...>]

I was wondering if the following pattern is supported, don't think so
but I may be missing something.

 

I would like to have a generic class wrap all my REST responses.

 

@GET

@Path(/somepath)

public GenericWrapper someMethod()

{

      ResponseObject response = New ResponseObject();

      return new GenericWrapper<response>(response);

 

}

 

The ResponseObject extends BasicResponse and is also annoted with JAX-B
@XmlRootEntity.

 

 

@XmlRootEntity

public class GenericWrapper<T extends BasicResponse>

{

    

    String  commondata;

    String othercommondata;

    String resultcode;

    ................

 

    T response;

 

    public GenericWrapper(T response)

    {

        this.response = response;

    }

}

 

This way it simplifes the number of concrete classes needed for
different response types. I don't think this works. Is there another
pattern for this or is it reasonable for the framework to  examine the
generics definition and search out the classes that extend BasicResponse
that have JAX-B annotations so proper marshalling can occur?

 

thanks

Mike Chack 
O: +1 408.526.4639 
M: +1 408.504.6594 
mc...@ci... 

 

Re: [Resteasy-developers] Problem with HTTP POST Method

[And F. <and...@ya...>]

Hi,

I am running in to an issue accessing the request parameters from the POST method implementation. From with in the service, I am unable to access the parameters set by the client. I am using the Resteasy 1.0 beta 8. I am not using any servlet filters. Looking at the forum, this issue will be resolved in beta 9. Can you please confirm?

Thanks

--------------------

//
// Server
//
@Post
@Produces("text/xml")
public String doSomething(@Context HttpServletRequest req) {
  String query = req.getParameter("Query");
  System.out.println("query = " + query);         // always null
  return "<Query>" + query + </Query>;
}

//
// Client using Apache HttpClient libraries
//
PostMethod method = new PostMethod("url");
method.addParameter("Query", "123");
:
HttpClient httpClient = new HttpClient();
int ret = httpClient.executeMethod(method);

//
// web.xml (simple and no servlet filters in place)
//

-------------------------



      

Re: [Resteasy-developers] Spring eye for the RESTEasy guy - part 1

[Bill B. <bb...@re...>]

Solomon Duskis wrote:
> Re ResourceExposingService - I guess it was a bad name... I basically 
> meant ResteasyRegistration.  I do hope this makes it into the RESTEasy core.
> 
> Re IoC container dependency: What I really want is a way to use the 
> Spring MVC framework right along side JAX-RS/RESTEasy.  It will allow me 
> to configure which requests go to Spring MVC Controllers/Struts 
> Actions/JAX-RS Resources and how to render Views/Producers with 
> Velocity/Freemarker/Tiles/JSP.  In order to get that to work properly, 
> I'll need to store the Registry et al in the Spring Application context 
> instead of the ServletContext.
> 

Why do you need access to the Registry?  And if you really do, can't it 
be manually registered?

> Perhaps I'll just vet some ideas in this group as to how I could use 
> RESTEasy towards my ends.  The means I use to achieve my ends may may be 
> helpful for other MVC and IoC integrations such as Struts2/Guice... I 
> know RESTEasy already works with Seam ;).
> 

Yes, please brainstorm.  I'm Spring ignorant beyond basic IoC so any 
insight would be invaluable.


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

Re: [Resteasy-developers] Spring eye for the RESTEasy guy - part 1

[Solomon D. <sd...@gm...>]

Re ResourceExposingService - I guess it was a bad name... I basically meant
ResteasyRegistration.  I do hope this makes it into the RESTEasy core.

Re IoC container dependency: What I really want is a way to use the Spring
MVC framework right along side JAX-RS/RESTEasy.  It will allow me to
configure which requests go to Spring MVC Controllers/Struts Actions/JAX-RS
Resources and how to render Views/Producers with
Velocity/Freemarker/Tiles/JSP.  In order to get that to work properly, I'll
need to store the Registry et al in the Spring Application context instead
of the ServletContext.

Perhaps I'll just vet some ideas in this group as to how I could use
RESTEasy towards my ends.  The means I use to achieve my ends may may be
helpful for other MVC and IoC integrations such as Struts2/Guice... I know
RESTEasy already works with Seam ;).

-Solomon

On Wed, Oct 8, 2008 at 4:16 PM, Bill Burke <bb...@re...> wrote:

> We wouldn't need a ResourceExposingService.  That is the Registry.  I see
> your point of the same class instantiated as different beans, but having the
> same relative resource API.
>
> Maybe something as simple as:
>
> public class ResteasyRegistration
> {
>   String getRootPath();
>   Object getTarget();
> }
>
>
>
> <bean name="MyBean" class="org.any.MyService"/>
> <bean name="MyBean2" class="org.any.MyService"/>
>
> Leave out the @Path annotation on the MyService class.
>
> <bean name="registration" class="org.jboss.resteasy.ResteasyRegistration">
>   <property name="rootPath">/x/1</property>
>   <property name="target" ref="MyBean"/>
> </bean>
>
> <bean name="registration2" class="org.jboss.resteasy.ResteasyRegistration">
>   <property name="rootPath">/x/2</property>
>   <property name="target" ref="MyBean2"/>
> </bean>
>
> Then we just modify the Spring adapter to look for instances of
> ResteasyRegistration.
>
>
> Solomon Duskis wrote:
>
>> 2) Having RestEasy configured purely in spring, including
>> configuration/management of the Registry and Dispatcher in Spring - I'll
>> fill in this idea in a future email.
>>
>>
> I don't want to be dependent on any IoC container.  There are a bunch out
> there:  Spring, Seam, Guice, JBoss MC, and even Java EE to some degree.
>  This is why I've focused on configuration via web.xml context-params.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>

Re: [Resteasy-developers] RESTEasy client changes

[Bill B. <bb...@re...>]

Solomon Duskis wrote:
> I refactored the ProxyFactory code a bit, and attached it as a .zip file 
> to this email.
> 
> Here's a summary of what I did:
> 
> 1) ClientInvoker:
>   A) I refactored the invoke method into smaller, overridable methods:
>      - generate base URI
>      - populate parameters
>      - retrieve results
>   
>   B) I moved the creation of Get/Put/Post/Delete HttpMethodBase into a 
> factory (HttpMethodBaseFactory).  I got rid of GetInvoker/PutInvoker... 
> and replaced them with a call to 
> HttpMethodBaseFactoy.createDefaultFactory(String method) which gets 
> called as part of the "retrieve results" step.  I did this so that the 
> methods in 1A can be overridden in an without interfering with the 
> HttpMethodBase object creation.
> 
>   The combination of those two changes should allow clever subclassing, 
> like adding extra parameters or caching a GET call.  An interface would 
> allow some fancy decorations: CachingClient -> 
> ProprietaryParameterAddingClient -> BaseClientInvokerl; however, I 
> didn't want to build that just yet without vetting the general idea with 
> the group.
>  
> 2) ProxyFactory;
>   A) I made it into an abstract class (I didn't bother with an 
> interface, so that I can keep the existing static methods and still keep 
> the ProxyFactory class)
>  
>   B) I added an abstract method createFactory(Class<T>) along with a 
> DefaultProxyFactory implementation that that has the original 
> ProxyFactory functionality.  A user will need to override the 
> ProxyFactory.createClientInvoker() in order to create the clever 
> subclass of ClientInvoker
>  

This wasn't the approach I was thinking of.  Think Servlet Filters but 
on the client.  Each filter (interceptor) could add whatever 
headers/data it wanted to the request (i.e. a custom security 
interceptor).  Each filter could process the response in a special way 
(for instance, the client-caching interceptor looks for Cache-Control 
headers in the response and caches accordingly).


> 
> As far as the caching client goes: I'm not quite sure which existing 
> caching solution best fits a RESTful request.

Read up on Cache-Control header.  Basically the server passes a response 
header that states the cache policy.  Its a pretty rich protocol.


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

Re: [Resteasy-developers] Spring eye for the RESTEasy guy - part 1

[Bill B. <bb...@re...>]

We wouldn't need a ResourceExposingService.  That is the Registry.  I 
see your point of the same class instantiated as different beans, but 
having the same relative resource API.

Maybe something as simple as:

public class ResteasyRegistration
{
    String getRootPath();
    Object getTarget();
}



<bean name="MyBean" class="org.any.MyService"/>
<bean name="MyBean2" class="org.any.MyService"/>

Leave out the @Path annotation on the MyService class.

<bean name="registration" class="org.jboss.resteasy.ResteasyRegistration">
    <property name="rootPath">/x/1</property>
    <property name="target" ref="MyBean"/>
</bean>

<bean name="registration2" class="org.jboss.resteasy.ResteasyRegistration">
    <property name="rootPath">/x/2</property>
    <property name="target" ref="MyBean2"/>
</bean>

Then we just modify the Spring adapter to look for instances of 
ResteasyRegistration.


Solomon Duskis wrote:
> 2) Having RestEasy configured purely in spring, including 
> configuration/management of the Registry and Dispatcher in Spring - I'll 
> fill in this idea in a future email.
> 

I don't want to be dependent on any IoC container.  There are a bunch 
out there:  Spring, Seam, Guice, JBoss MC, and even Java EE to some 
degree.  This is why I've focused on configuration via web.xml 
context-params.



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

[Resteasy-developers] Spring eye for the RESTEasy guy - part 1

[Solomon D. <sd...@gm...>]

The current Spring/RESTEasy integration is pretty slick.  I'd like to
propose a couple of changes that might make it even better.

1) ResourceExposingService:  Expose a spring bean with jax-rs annotations at
different contexts.  Think of it as writing code for a sub-resource, and
exposing it via Spring.

Most of the time, one Class maps to one configuration (either Singleton or
Prototype).  Sometimes, it may be convenient to have two or more
configurations of the same Class.  For example, take a GenericCRUDResource
which does generic crud operations on a specific JPA Entity type which is
also JAXB annotated - GET "/" maps some group list functionality;
GET/PUT/DELETE "/{id} and POST "/" would do the appropriate CRUD operation.
All that GenericCRUDResource needs is a specific Domain Class, an
EntityManager and a unique basePath.

We can do the following in the Spring XML:

<!-- create & configure a book and author GenericCRUDResource -->

<bean class="com.jboss.resteasy.<something>.ResourceExposingService">
  <property name="resource" ref="bookResource" />
  <property name="basePath" value="/books/" />
</bean>

<!-- spring namespace wrapper -->
<resteasy:expose resource="authorResource" basePath="/authors/" />

The processing of ResourceExposingService is pretty straight forward to add
to SpringBeanProcessor

else if (bean instanceof ResourceExposingService)
{
   ResourceExposingService exposer = (ResourceExposingService) bean;
   registry.addSingletonResource(exposer.getResource(),
exposer.getBasePath());
}

2) Having RestEasy configured purely in spring, including
configuration/management of the Registry and Dispatcher in Spring, plus
integration with the Spring MVC framework - I'll fill in this idea in a
future email.

What do you think about item 1?

-Solomon

[Resteasy-developers] Spring eye for the RESTEasy guy - part 1

[Solomon D. <sd...@gm...>]

The current Spring/RESTEasy integration is pretty slick.  I'd like to
propose a couple of changes that might make it even better.

1) ResourceExposingService:  Expose a spring bean with jax-rs annotations at
different contexts.  Think of it as writing code for a sub-resource, and
exposing it via Spring.

Most of the time, one Class maps to one configuration (either Singleton or
Prototype).  Sometimes, it may be convenient to have two or more
configurations of the same Class.  For example, take a GenericCRUDResource
which does generic crud operations on a specific JPA Entity type which is
also JAXB annotated - GET "/" maps some group list functionality;
GET/PUT/DELETE "/{id} and POST "/" would do the appropriate CRUD operation.
All that GenericCRUDResource needs is a specific Domain Class, an
EntityManager and a unique basePath.

We can do the following in the Spring XML:

<!-- create & configure a book and author GenericCRUDResource -->

<bean class="com.jboss.resteasy.<something>.ResourceExposingService">
  <property name="resource" ref="bookResource" />
  <property name="basePath" value="/books/" />
</bean>

<!-- spring namespace wrapper -->
<resteasy:expose resource="authorResource" basePath="/authors/" />

The processing of ResourceExposingService is pretty straight forward to add
to SpringBeanProcessor

else if (bean instanceof ResourceExposingService)
{
   ResourceExposingService exposer = (ResourceExposingService) bean;
   registry.addSingletonResource(exposer.getResource(),
exposer.getBasePath());
}

2) Having RestEasy configured purely in spring, including
configuration/management of the Registry and Dispatcher in Spring - I'll
fill in this idea in a future email.

What do you think about item 1?

-Solomon

Re: [Resteasy-developers] RESTEasy client changes

[Solomon D. <sd...@gm...>]

sorry...  I meant that I built these classes off of the 1.0 beta 8 source
distribution.

On Tue, Oct 7, 2008 at 9:46 PM, Solomon Duskis <sd...@gm...> wrote:

> I refactored the ProxyFactory code a bit, and attached it as a .zip file to
> this email.
>
> Here's a summary of what I did:
>
> 1) ClientInvoker:
>   A) I refactored the invoke method into smaller, overridable methods:
>      - generate base URI
>      - populate parameters
>      - retrieve results
>
>   B) I moved the creation of Get/Put/Post/Delete HttpMethodBase into a
> factory (HttpMethodBaseFactory).  I got rid of GetInvoker/PutInvoker... and
> replaced them with a call to
> HttpMethodBaseFactoy.createDefaultFactory(String method) which gets called
> as part of the "retrieve results" step.  I did this so that the methods in
> 1A can be overridden in an without interfering with the HttpMethodBase
> object creation.
>
>   The combination of those two changes should allow clever subclassing,
> like adding extra parameters or caching a GET call.  An interface would
> allow some fancy decorations: CachingClient ->
> ProprietaryParameterAddingClient -> BaseClientInvokerl; however, I didn't
> want to build that just yet without vetting the general idea with the group.
>
> 2) ProxyFactory;
>   A) I made it into an abstract class (I didn't bother with an interface,
> so that I can keep the existing static methods and still keep the
> ProxyFactory class)
>
>   B) I added an abstract method createFactory(Class<T>) along with a
> DefaultProxyFactory implementation that that has the original ProxyFactory
> functionality.  A user will need to override the
> ProxyFactory.createClientInvoker() in order to create the clever subclass of
> ClientInvoker
>
>
> As far as the caching client goes: I'm not quite sure which existing
> caching solution best fits a RESTful request.  If I understand HTTP
> correctly, I believe that the server side determines how long to cache a
> resource.  I'm not quite sure how that fits in with existing caching
> solutions which usually have full control over the caching strategies.
> Also, I'm not quite sure how ETags fit in here.
>
> BTW, I used the source from the 0.8 source distribution.
>
> -Solomon
>