2.4.1-SNAPSHOT is the trunk version - so please check it out if you
decide to work on a pacth, I'll then backmerge it to
2.3.5-SNAPSHOT
Cheers, Sergey
On Thu, May 12, 2011 at 9:51 PM, Biju Nair <biju74tec...@gmail.com> wrote:
> Which version of CXF you are working on?
>
> I was working with 2.3.1.
>
> On Thu, May 12, 2011 at 1:08 PM, Sergey Beryozkin <sberyoz...@gmail.com>wrote:
>
>> Hi
>>
>> On Thu, May 12, 2011 at 8:21 PM, Biju Nair <biju74tec...@gmail.com> wrote:
>> > Just to clarify,
>> >
>> > the user bean will be something like,
>> > class User{
>> > Map<String, String> params;
>> > }
>> >
>> > Request Data will be user.params.k1=v1&*user.*params.k2=v2
>>
>> Yes if User is a nested bean, otherwise just
>> params.k1=v1¶ms.k2=v2
>>
>> if we have FormParam("") User
>>
>> >
>> > Finally, the params map will have [{k1=v1},{k2=v2}]
>> >
>> > Right?
>> Yes
>>
>> >
>> > I will check this and let you know.
>> >
>> Ok, thanks. By the way I'm planning to have this code reused for
>> handling more involved FIQL queries, ex, one can do
>>
>> /books?_s=id=gt=1
>>
>> "Find all books with id greater than 1"
>>
>> but we can't express the same query if Book happens to have a nested
>> ID bean, etc:
>>
>> /books?_s=id=gt=id.1
>>
>> Cheers, Sergey
>>
>> > Biju B
>> >
>> > On Thu, May 12, 2011 at 10:52 AM, Sergey Beryozkin <sberyoz...@gmail.com
>> >wrote:
>> >
>> >> Hi
>> >>
>> >> On Thu, May 12, 2011 at 5:55 PM, Biju Nair <biju74tec...@gmail.com>
>> wrote:
>> >> > Yes I understood that we don't need two solution for same problem :).
>> >> >
>> >> > Just want you let know, if you try to put something like
>> >> > "testaddress.City=Pleasanton&testAddress.stateName=CA"
>> >> > testAddress.stateName will not be populated. What I saw in your code
>> is,
>> >> for
>> >> > first parameter the TestAddress instance is created and put into map
>> as
>> >> > testaddress=<object> and in second parameter new TestAddress object is
>> >> > creates and put into map as testAddress=<object>.
>> >> >
>> >> > Code Says ==> parsedValues.put(beanKey, value);
>> >> >
>> >> I see, I checked the actual property name, such as "set+ 'stateName'"
>> >> is checked against available methods (and I guess fields) in a
>> >> case-insensitive way...
>> >>
>> >> > Anyway thanks for the discussion.
>> >> >
>> >> cool, thanks for starting it up
>> >>
>> >> > Can you elaborate on "Maps are not supported for example" - Let me see
>> >> > whether I can contribute?
>> >> >
>> >> Awhile back, a user asked about it but I recall I just did not get to
>> >> doing it, example
>> >>
>> >> user.params.k1=v1¶ms.k2=v2
>> >>
>> >> where a User bean has Map<String, String> property, which can be handy
>> >> in some cases too.
>> >> have a look please if you get a chance
>> >>
>> >> Cheers, Sergey
>> >>
>> >> > Biju B
>> >> >
>> >> > On Thu, May 12, 2011 at 2:43 AM, Sergey Beryozkin <
>> sberyoz...@gmail.com
>> >> >wrote:
>> >> >
>> >> >> Hi
>> >> >>
>> >> >> On Wed, May 11, 2011 at 5:34 PM, Biju Nair <biju74tec...@gmail.com>
>> >> wrote:
>> >> >> > Thanks for the reply.
>> >> >> >
>> >> >> > Just for clarification,
>> >> >> > If I have a Employee bean as follows,
>> >> >> > class Employee{
>> >> >> > String name;
>> >> >> > Address homeAddress;
>> >> >> > //getters and setters are there
>> >> >> > }
>> >> >> >
>> >> >> > class Address{
>> >> >> > String line1;
>> >> >> > String line2;
>> >> >> > //getters and setters are there
>> >> >> > }
>> >> >> > there is a rest service as String update(@FormParam("") Employee
>> >> >> employee)
>> >> >> >
>> >> >> > In the current approach, we need to pass request data as *
>> >> >> > name=Joe&homeAddress.line1=MyLocation&homeAddress.line2=MyStreet*
>> >> >> >
>> >> >> > which means we need to have homeAddress as case sensitive right?
>> and
>> >> it
>> >> >> > won't work with "homeaddress.line1" right?
>> >> >>
>> >> >> No, the comparison is case-insensitive.
>> >> >>
>> >> >> > Also later if we try to change the variable names we need to ask
>> all
>> >> the
>> >> >> > clients to change the request params. Am I right or something
>> missing
>> >> >> here.
>> >> >> >
>> >> >>
>> >> >> I guess some care has to be taken with regard to refactoring the bean
>> >> >> class which is meant to capture the input from
>> >> >> remote clients.
>> >> >>
>> >> >> If you have a User.setAddress() method which is meant to capture an
>> an
>> >> >> 'address' property then yes, if you go ahead and remove it or rename
>> >> >> it to setUserAddress then yes, "address" property won't be injected -
>> >> >> but customers does not have to be affected in such cases - replacing
>> >> >> the form submission payload can be easily done on the server side,
>> ex,
>> >> >> at the RequestFilter level or better yet, by providing a custom
>> >> >> MessageBodyReader which extends CXF FormEncodingProvider and
>> overrides
>> >> >> its populateMap method - let superclass to read the data and then
>> just
>> >> >> replace the key 'address' with say 'customerAddress'
>> >> >>
>> >> >> Look, as I tried to say in the previous email, it's basically not
>> >> >> about CXF solution is better then yours, etc :-). I just don't think
>> >> >> we should have two solutions for this case 'shipped' with CXF. The
>> CXF
>> >> >> one may not be ideal but it has its benefits too, one of them is that
>> >> >> WADLGenerator can understand such beans when generating query or form
>> >> >> parameters, etc, the other one is that JAX-RS proxies understand how
>> >> >> to deal with them, etc.
>> >> >>
>> >> >> I'd encourage you to help us to improve the existing solution if you
>> >> >> find some drawbacks. Maps are not supported for example.
>> >> >>
>> >> >> Thanks, Sergey
>> >> >>
>> >> >> Cheers, Sergey
>> >> >>
>> >> >> > Please confirm.
>> >> >> >
>> >> >> > Biju B
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Wed, May 11, 2011 at 1:45 AM, Sergey Beryozkin <
>> >> sberyoz...@gmail.com
>> >> >> >wrote:
>> >> >> >
>> >> >> >> Hi
>> >> >> >>
>> >> >> >> On Tue, May 10, 2011 at 10:07 PM, Biju Nair <
>> biju74tec...@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 <
>> >> >> sberyoz...@gmail.com
>> >> >> >> >wrote:
>> >> >> >> >
>> >> >> >> >> Hi
>> >> >> >> >>
>> >> >> >> >> Please see comments inline
>> >> >> >> >>
>> >> >> >> >> On Tue, May 10, 2011 at 8:29 PM, Biju Nair <
>> >> biju74tec...@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
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Sergey Beryozkin
>> >> >>
>> >> >> Application Integration Division of Talend
>> >> >> http://sberyozkin.blogspot.com
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Sergey Beryozkin
>> >>
>> >> Application Integration Division of Talend
>> >> http://sberyozkin.blogspot.com
>> >>
>> >
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Application Integration Division of Talend
>> http://sberyozkin.blogspot.com
>>
>
