Re: [Resteasy-users] Client Framework and Subresource Locators
I guess my question is less about the use of the client framework in general, but about a scenario as described in section 44.2. of the RestEASY documentation ("Sharing an interface between client and server"), i.e. the case where the server-side interfaces are re-used on the client side, to avoid repetition. This would not be possible in the example described earlier. > 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@... >> 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
Re: [Resteasy-users] Client Framework and Subresource Locators
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
[Resteasy-users] Client Framework and Subresource Locators
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