On Mar 31, 2009, at 6:14 PM, Patrick Sansoucy wrote:
> Sorry for the double post ...
> I missed the last email and thought it did not get in.
I am CC'ing just in case :-) are you receiving emails from the list?
> 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 :) ).
No offense taken :-) We often drive new features based on requirements
from developers.
> 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 ?
Not yet, if you would like this can please log an issue so we can
track it.
Would the plain JavaBean approach (like i prototyped) be sufficient
for your purposes?
I am a bit reluctant to reuse @Path on bean because it is being with
different semantics i.e. what is annotated is not a resource class.
However, some different annotations could be used.
> I want to avoid coding something that will pop up within the API soon.
I think you will need to code something up in the interim (it is
unlikely this feature will be implemented in time for the 1.0.3
release which will happen in a week or two). Perhaps what you code
could be contributed to the issue?
Paul.
> 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.
>