Sorry for the double post ...
I missed the last email and thought it did not get in.
I agree completely, having the uri builder mechanism from a pojo would do
the job. I strapped this example together just to get the ball rolling. I
currently have a client to develop using REST which has 10 plus parameter to
encode within the url and thought the current way on doing it was not
'elegant' in my context ( don't want to offend anyone here :) ). I wanted to
go with the least custom code possible follow current Jersey API's as much
as possible. Anyway, is this something planned within the Jersey API ? I
want to avoid coding something that will pop up within the API soon.
Thanks for the help and insights
Patrick S.
> Hi Patrick,
>
> Did you see my response to a previous email you sent, on the 24th March, on
> a similar subject?
>
>
> http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users+Using+annotated+POJOs+to+build+client+request#query:list%3Anet.java.dev.jersey.users%20Using%20annotated%20POJOs%20to
> %20build%20client%20request+page:1+mid:fm5talthbic6bbow+state:results
>
> In you example what is the representation (request entity body) sent in the
> post request?
>
> The problem i have with your proposed solution is it mixes the request
> entity 'w' with the request URI. What if you were going to do the same thing
> with a GET request, for example, that does not send request entities ?
>
> I think the right approach is to consider the separate pieces of
> functionality like creating a URI path from a bean and that URI can be used
> to create a WebResource and then that WebResource can be reused. Then steps
> may be combined for eas of use, for example:
>
> BeanUri bu = new BeanUri(); // set state on bu
>
> Client c = .... c.resource(bu);
>
> might be equivalent to:
>
> BeanUri bu = new BeanUri(); // set state on bu
>
> Client c = .... URI u = c.createUri(bu); c.resource(bu);
>
> Paul.
>
>