Return-Path: 
 <users-return-17879-apmail-cxf-users-archive=cxf.apache.org@cxf.apache.org>
Delivered-To: apmail-cxf-users-archive@www.apache.org
Received: (qmail 51418 invoked from network); 15 Oct 2009 10:03:21 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 15 Oct 2009 10:03:21 -0000
Received: (qmail 22900 invoked by uid 500); 15 Oct 2009 10:03:20 -0000
Delivered-To: apmail-cxf-users-archive@cxf.apache.org
Received: (qmail 22799 invoked by uid 500); 15 Oct 2009 10:03:20 -0000
Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@cxf.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@cxf.apache.org>
List-Post: <mailto:users@cxf.apache.org>
List-Id: <users.cxf.apache.org>
Reply-To: users@cxf.apache.org
Delivered-To: mailing list users@cxf.apache.org
Received: (qmail 22789 invoked by uid 99); 15 Oct 2009 10:03:20 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Oct 2009 10:03:20 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [131.239.30.131] (HELO ntmamx1.progress.com) (131.239.30.131)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Oct 2009 10:03:12 +0000
Received: from ntmamx1.progress.com (127.0.0.1) by ntmamx1.progress.com
 (MlfMTA v3.2r9) id hqrplq0171st for <users@cxf.apache.org>;
 Thu, 15 Oct 2009 06:02:48 -0400 (envelope-from <sberyozk@progress.com>)
Received: from progress.com ([172.16.3.168])
	by ntmamx1.progress.com (SonicWALL 7.1.1.1995)
	with ESMTP; Thu, 15 Oct 2009 06:02:48 -0400
Received: from NTEXFE02.bedford.progress.com (ntexfe02-lb [10.128.10.27])
	by progress.com (8.13.8/8.13.8) with ESMTP id n9FA2qvu006195
	for <users@cxf.apache.org>; Thu, 15 Oct 2009 06:02:52 -0400 (EDT)
Received: from sberyoz ([10.5.2.31]) by NTEXFE02.bedford.progress.com over TLS
 secured channel with Microsoft SMTPSVC(6.0.3790.3959);
	 Thu, 15 Oct 2009 06:02:51 -0400
Message-ID: <011b01ca4d7e$a85521d0$1f02050a@emea.progress.com>
From: "Sergey Beryozkin" <sberyozk@progress.com>
To: <users@cxf.apache.org>
References: 
 <4A01D8A3B99F4E4F8FE11C136403B22603ACC735@MAIL03.bedford.progress.com>
Subject: Re: ParameterHandler Question
Date: Thu, 15 Oct 2009 11:02:48 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-OriginalArrivalTime: 15 Oct 2009 10:02:51.0489 (UTC)
 FILETIME=[A818B510:01CA4D7E]
X-Mlf-Version: 7.1.1.1995
X-Mlf-UniqueId: o200910151002480394484
X-Virus-Checked: Checked by ClamAV on apache.org

Hi Eric

It's a typo, sorry. Just fixed it. ParameterHandler implementations can be registered as providers; there're examples showing how to 
register  providers, so I don't show it every time to save some space. For ex, here's how you can do it from Spring :

<jaxrs:server address="/">
<jaxrs:providers>
   <ref bean="paramHandler"/>
</jaxrs:providers>
</jaxrs:server>

<bean id="paramHandler" "org.apache.cxf.systest.jaxrs.MapParamHandler"/>


thanks, Sergey

----- Original Message ----- 
From: "Eric Johnson" <EMJOHNSO@progress.com>
To: <users@cxf.apache.org>
Sent: Wednesday, October 14, 2009 10:05 PM
Subject: ParameterHandler Question


I was looking through the documentation on JAX-RS and found this:
CXF JAXRS supports ParameterHandler extensions which can be used to deal
with method parameters annotated with one of the JAXRS parameter
annotations :
public class MapHandler implements ParameterHandler<Map> {
    public Map fromString(String s) {...}
}

@Path("/")
public class Service {


    @PUT
    @Path("{id}")
    public Response update(@PathParam("g") Map m, byte[] bytes) {
        ...
    }
}
Note that ParameterHandlers can not be used to deal with parameters
representing a message body, "byte[] byte" in this example.
MessageBodyReaders have to deal with this task. That said, a given
MessageBodyReader implementation can also implement ParameterHandler.
ParameterHandlers can be registered as providers either from Spring or
programmatically.
I'm feeling a little stupid because I cannot figure out from the example
code what is going on. I see that the PathParam is looking for the path
segment "g" which does not appear to exist in the URI template and wants
to map that value into a Map. I also see that there is a
ParameterHandler implemented that maps a PathParam to a Map. So, does
the ParameterHandler get used when the URI template variable does not
exist? Or is it just a typo? Or does it not matter?
Also could an example of how the ParameterHandler is registered be
added?