[Resteasy-users] Client Framework and Subresource Locators

2012-12-15 Thread Richard Cissee
Hello,

the client framework creates proxies for resource classes and now for 
subresource locators as well (see e.g. Issue 589). These are always 
created for the class indicated by the static return type of the 
respective method, e.g. for a resource locator with the method

@Path({number})
Chapter getChapter(@PathParam(number) int number)

a proxy for Chapter.class is created and used. The jax-rs 
specification, however, states that An implementation MUST dynamically 
determine the class of object returned rather than relying on the static 
sub-resource locator return type (section 3.4.1). Thus, the server may 
actually use a subclass of Chapter, and process the request in a 
different manner than expected by the client framework.

IMO, this basically means that Java interfaces alone cannot in all cases 
be used as the complete specification of the server's ReST interface, 
and consequently may be insufficient as basis for the client framework. 
Any thoughts on how to deal with this?

Regards,
Richard

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users


Re: [Resteasy-users] Client Framework and Subresource Locators

2012-12-15 Thread Bill Burke
What does that have to do with the client framework? The client 
framework is just a set of predefined interfaces you invoke on, which is 
different than the server where any object can be returned as a method.

On 12/15/2012 9:21 AM, Richard Cissee wrote:
 Hello,

 the client framework creates proxies for resource classes and now for
 subresource locators as well (see e.g. Issue 589). These are always
 created for the class indicated by the static return type of the
 respective method, e.g. for a resource locator with the method

 @Path({number})
 Chapter getChapter(@PathParam(number) int number)

 a proxy for Chapter.class is created and used. The jax-rs
 specification, however, states that An implementation MUST dynamically
 determine the class of object returned rather than relying on the static
 sub-resource locator return type (section 3.4.1). Thus, the server may
 actually use a subclass of Chapter, and process the request in a
 different manner than expected by the client framework.

 IMO, this basically means that Java interfaces alone cannot in all cases
 be used as the complete specification of the server's ReST interface,
 and consequently may be insufficient as basis for the client framework.
 Any thoughts on how to deal with this?

 Regards,
  Richard

 --
 LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
 Remotely access PCs and mobile devices and provide instant support
 Improve your efficiency, and focus on delivering more value-add services
 Discover what IT Professionals Know. Rescue delivers
 http://p.sf.net/sfu/logmein_12329d2d
 ___
 Resteasy-users mailing list
 Resteasy-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/resteasy-users


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

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users