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
Finally, the params map will have [{k1=v1},{k2=v2}]
Right?
I will check this and let you know.
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
>
