i don't see the SVN branch.
I am trying to change in http://svn.apache.org/repos/asf/cxf/trunk - is that
ok? If not can you sen me the SVN link?
On Fri, May 13, 2011 at 1:48 AM, Sergey Beryozkin <sberyoz...@gmail.com>wrote:
> 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
> >>
> >
>
