On Sep 4, 2009, at 11:00 AM, Felipe Gaścho wrote:
> 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 ?
>
I am not referring to an HTTP proxy.
I am referring to the Java dynamic proxy class support. Basically it
is possible to proxy an interface to provide an implementation of that
interface, see:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Proxy.html
Paul.
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>