users@jersey.java.net

Re: [Jersey] Client java stubs with Jersey

From: Felipe Gaúcho <fgaucho_at_gmail.com>
Date: Fri, 4 Sep 2009 11:00:49 +0200

why not just to use the default Java SE prox mechanism through Properties ??

like:

                Properties systemSettings = System.getProperties();
                systemSettings.put("http.proxyHost", "the.proxy.com");
                systemSettings.put("http.proxyPort", "8080");
                System.setProperties(systemSettings);

and after that the HTTP calls will work normally.. isnst it ?

On Fri, Sep 4, 2009 at 10:13 AM, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
>
> On Sep 3, 2009, at 4:53 PM, Andrew Ochsner wrote:
>
> I'm not sure I understand what you mean by "proxy based approach"  Do you
> mean a set of richer classes in a client side "SDK" that proxies the real
> HTTP calls?
>
>
> I  mean something like the following interface:
>  public interface ProxyResource {
>    @Path("{id}")
>    @GET
>     String get(@PathParam("id") int id);
>  }
> with:
>   Client c = ...
>   ProxyResource pr = c.proxy("http://localhost/xyz", ProxyResource.class);
>   String s = pr.get(1);
> or:
>   WebResource r = ...
>   ProxyResource pr = c.proxy(ProxyResource.class);
>   String s = pr.get(1);
> rather than:
>   Client c = ...
>   WebResource r = c.resource("http://localhost/xyz").path(1);
>   String s = r.get(String.class);
>
> Paul.
>
> On Thu, Sep 3, 2009 at 9:05 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>
>> Hi,
>>
>> On a general point: I would be interested in hearing more feedback from
>> other Jersey users f they would like proxy support or if they are happy with
>> the Jersey client API as is.
>>
>>
>> On Sep 3, 2009, at 2:46 PM, gerard davison wrote:
>>
>>>
>>> Paul,
>>>
>>> I can understand the desire for loose coupling; but from a tools
>>> developer perspective almost the first thing people ask for is the ability
>>> to generate some kind of static java interface for a given WADL.
>>
>> Old habits die hard :-)
>>
>>
>>> I can see the argument against it; but in many cases your "basic
>>> work-a-day" developer is not going to understand the finer distinctions in
>>> REST and wants a simple API to program against. This is the same thing we
>>> see with JAX-WS/WSDL where most user appear to treat it as a black box.
>>>
>>> Now with Jersey, as it currently stands, we can at least generate some
>>> JAXB files for the user if we expose the grammar using the WADL extension. I
>>> do wonder if this should be the default as it would make tooling much each
>>> to write. What is the reasoning behind not making this a default feature of
>>> the WADL generator?
>>>
>>
>> Time and TLC in this area :-)
>>
>>
>>> As to the client interface, I guess this along with HATEOAS is something
>>> for JAX-RS 2.x, I do like how RESTEasy present these client interfaces:
>>>
>>>
>>> http://jboss.org/file-access/default/members/resteasy/freezone/docs/1.1.GA/userguide/html/RESTEasy_Client_Framework.html
>>>
>>> I am not saying this should be the only way to talk to a service; but it
>>> is certainly a nice model to present to developer who want something more
>>> concrete.
>>
>> I avoided a proxy-based approach because JAX-RS artifacts do not translate
>> to the client side in all cases e.g. returning of Response for example, or
>> sub-resource locators. Which is why RESTEasy has to deviate and have a class
>> such as ClientResponse. I am not really criticizing here just making an
>> observation. RESTEasy is doing it's best to work around the fact that JAX-RS
>> 1.x was designed for server-side only.
>>
>> In general this approach can create the illusion that one can define a set
>> of interfaces that you implement on the server side and can reuse on the
>> client side. This approach can be limiting for a number reasons:
>>
>> 1) It makes it harder to implement the service. HTTP is the interface,
>> there is no need to define interfaces for your
>>    resources unless it is required for some sort of internal architectural
>> detail.
>>
>> 2) If the client is also depending on those interfaces it may make it
>> harder to evolve the server side. With JAX-RS
>>     it is possible to do all sorts of refactorings while from a HTTP
>> perspective the client will not notice anything,
>>     in addition to adding more sub-resources or support for more media
>> types.
>>
>> 3) I get the impression that for a fully fleshed out client API to a
>> service a proxy-based approach or the builder
>>     approach is not wholly sufficient and it is better to provide a
>> library. This is in fact what the Sun Cloud team
>>     have done, using the Jersey API underneath to make it easier for them
>> to implement this API.
>>
>>
>> I can see the merit in some cases for a proxy-based approach if the
>> artifacts are independent from the server implementation and created by the
>> consumer or by the provider.
>>
>> But, even then in terms of LOC you can achieve similar results using a
>> fluent-based API. And in terms of reuse i deliberately designed WebResource
>> to be reusable and for child resources to be easily created, so you can be
>> DRY.
>>
>> I think the one clear advantage of a proxy-based approach is it can act as
>> a form of documentation in code and it makes it easier to write code when
>> using an IDE. (Fluent APIs are harder to document with JavaDoc.)
>>
>> Even though i am somewhat cold to lukewarm on the idea of proxies for
>> clients i suspect any JAX-RS 2.x effort will likely specify a solution in
>> addition to a fluent-based API.
>>
>>
>> What i would really like to see is the following tooling: having docs and
>> code completion with the Jersey client API based on dynamic analysis of WADL
>> obtained from the service. It could even provide snippets of template Jersey
>> client code that one could copy and paste. The nice thing about this is it
>> will work with any service that provides WADL (e.g. Zembly uses WADL a lot
>> for consuming services and that WADL could be reused).
>>
>> Paul.
>>
>>> It is also something we can easily give the users to get them going. I
>>> have looked at the wadl2java project; but would prefer from a simplicity
>>> point of view to be able to point users at some part of the Jersey project.
>>>
>>> Cheers,
>>>
>>> Gerard
>>>
>>>
>>> On 19:59, Paul Sandoz wrote:
>>>>
>>>> <div class="moz-text-flowed" style="font-family: -moz-fixed">On Sep 2,
>>>> 2009, at 9:31 AM, xworker wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> I'm using Jersery for ws in my project. I've got a JPA backend with
>>>>> lots of
>>>>> entitys. Question:
>>>>>
>>>>> How do I generate java POJO stubs from my Jersey ws? For SOAP I was
>>>>> able to
>>>>> generate client-side stubs, but not for REST?
>>>>
>>>> I advise against creating Java client stubs from Java server artifacts
>>>> because they make a tight coupling between client and server-side code (but
>>>> see later).
>>>>
>>>>
>>>>>
>>>>> Frontend is a backingbean with JSF pages.
>>>>>
>>>>> <code>
>>>>> wr =
>>>>>
>>>>> client.resource("http://localhost:8080/pe-backend/resources/activities");
>>>>>      activityList = wr.get(new GenericType<List<Activity>>() {
>>>>>      });
>>>>> </code>
>>>>>
>>>>> How shouold my backingbean know what Activity is?
>>>>>
>>>>
>>>> Human readable documentation of the service to be read by the developer.
>>>> Because the client is separated from the server you can also do:
>>>>
>>>>  wr =
>>>> client.resource("http://localhost:8080/pe-backend/resources/activities");
>>>>  activityArray = wr.get(Activity[].class);
>>>>
>>>> or perhaps use a different version of Activity (JAXB is somewhat
>>>> flexible in terms of consuming documents with additional XML it does not
>>>> understand). Or use some XPath on DOM.
>>>>
>>>> WADL can be used to help create the human readable documentation that
>>>> can be served as part of the service. Jersey dynamically creates a WADL
>>>> description of the service, see also here:
>>>>
>>>>  http://wikis.sun.com/display/Jersey/WADL
>>>>
>>>> If you really want static client stubs you could use the wadl2java
>>>> facility available from:
>>>>
>>>>  https://wadl.dev.java.net/
>>>>
>>>> Paul.
>>>> </div>
>>>>
>>>
>>> --
>>> Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
>>> Oracle JDeveloper Web Service Tooling Development
>>> Oracle Corporation UK Ltd is a company incorporated in England & Wales.
>>> Company Reg. No. 1782505.
>>> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>>>
>>> Blog http://kingsfleet.blogspot.com
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
>



-- 
Looking for a client application for this service:
http://fgaucho.dyndns.org:8080/footprint-service/wadl