cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Custom Reuqest Param Name for Bean Request Object
Date Wed, 11 May 2011 08:45:02 GMT
Hi

On Tue, May 10, 2011 at 10:07 PM, Biju Nair <biju74techie@gmail.com> wrote:
> Thanks for the reply.
>
> But in the first approach the client users has to follow Java naming
> conventions (espc a non-java client) right?
Clients use "user.name" or "user.address.value" if they need to, the
difference between the two approaches
in that with your annotations you can selectively point to a
particular field and say this is what "user.name" has to be mapped to,
while with the default approach one has to make sure nested beans are
available.

>
> Regarding the MultiValueMap, i like the idea, but not for Bean based. Here
> the developers need to convert the map to Bean right?
>
> I still prefer to use *@FormParam("") object*, because this looks like
> standard in CXF for primitive type arguments. *@FormParam("identifier") id.*

I like @FormParam("") too, it's a  CXF extension (using ""), but it
allows for capturing many values while still allowing for some
flexibility re property types  as opposed to using  MultiValuedMap
(which is JAX-RS compliant).

> **
> I think you can ask the same contributer to include the annotation approach
> or some custom way of declaring user-defined names, rather than java
> variables.
>

As I said the problem is how to have "user.a.b.c" mapped to a
particular property. CXF has one solution for it which I think is good
enough. Your solution is also interesting but I'm not sure CXF should
multiple solutions for this particular issue

Thanks, Sergey
> Biju B
>
> On Tue, May 10, 2011 at 1:22 PM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:
>
>> Hi
>>
>> Please see comments inline
>>
>> On Tue, May 10, 2011 at 8:29 PM, Biju Nair <biju74techie@gmail.com> wrote:
>> > Hi Team,
>> >
>> > Currently I was helping a team in building rest based services using CXF.
>> I
>> > noticed that for bean based service arguments (*Ex. String
>> > getData(@FormParam("") TestObj tObj)*)
>> > you have to include @FormParam with empty qualifer name and the request
>> > parameter should follow bean property naming conventions. Say example
>> > if TestObj has a property 'userName' (which is java style) then the
>> request
>> > parameter should be userName=Joe.
>> > But in our requirement (mostly everywhere) the request parameters need
>> not
>> > use the Java Style. Here we were asked to use 'user.name'.
>> >
>> > I know for non-bean based parameters CXF supports this as @FormParam("
>> > user.name") String userName, Is this possible for Bean Based also?
>> >
>> > As part of providing solution to team, I wrote a CXF Request Handler,
>> > which transforms all the request based parmeters to bean based.
>> > Now the TestObj will looks like,
>> > class TestObject {
>> >       @RequestParam("user.name")
>> >       String userName;
>> > ...
>> > }
>> > Using the @ReuestParam I will be identifying the actual request param.
>> > The component I wrote supports primitives, nested beans and collections
>> > also.
>> >
>> That is interesting, however I think your requirement can already be
>> handled:
>>
>> public class TestObject {
>>    public User getUser() {
>>         return new User();
>>    }
>>    public void setUser(User user) {}
>> }
>>
>> public class User {
>>    public String getName() {
>>         return name;
>>    }
>>    public void setName(String name) {}
>> }
>>
>> That is more verbose that your solution but the user who contributed
>> the patch earlier on did a lot of work for nested beans to work, with
>> collections supported as well. And no extra annotations is required.
>>
>> Another option is just use MultivaluedMap in case of form submissions
>> or explicit FormParam("user.name")
>>
>> What do you think ?
>>
>>
>> Cheers, Sergey
>>
>> > *My Suggestion is can you include this feature in next version of CXF?
>> and
>>  > Can I contribute my code?*
>> >
>> > Biju B
>> >
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Application Integration Division of Talend
>> http://sberyozkin.blogspot.com
>>
>



-- 
Sergey Beryozkin

Application Integration Division of Talend
http://sberyozkin.blogspot.com

Mime
View raw message