Thanks for the fast reply ...
On Tue, Mar 31, 2009 at 12:26 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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?
>
Just subscribed, so I should be fine from now on ...
>
> 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.
>
Done, Issue 253
> Would the plain JavaBean approach (like i prototyped) be sufficient for
> your purposes?
>
Think so, if I understand properly, I would just need to do a post on the
web resource to get the result ?
Also, could the following be done with the prototype you mentioned ? I would
like to be able to avoid creating resources for each use.
BeanUri bu = new BeanUri();
// set state on bu
Client c = .... c.resource(bu);
// post c
// set another state on bu
// post c
> 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.
>
No problem with that, I agree that confusion may arise from this ... The
only point I saw of re-using the annotation was if one could find a way to
build a single pojo for server AND client so it could be used like an API.
But I doubt this would simple and achievable in a short to mid term.
>
> 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?
>
Thanks for the info on the release ... As for the code contribution, I will
certainly look into it.
>
> Paul.
>
>
Thank you very much !
Patrick S.