By the way, if one needs to get the parameter names only (without the values)
in request filters, then the simplest way (starting to 2.2.3) is to do :
List<Parameter> parameter =
message.getExchange().getContent(OperationResourceInfo.class).getParameters();
Each Parameter instance will tell you what type of parameter it is (path,
query, request body), its name (like 'id' in @PathParam("id")), its position
in the actual resource method, default value if any and if its value is
supposed to be decoded or not. It will work even if the no-annotations
feature was used...
cheers, Sergey
Sergey Beryozkin-2 wrote:
>
> Hi Kynan
>
> Yes, an initial attempt to match an operation is done before request
> handlers are called. It's unfortunate the matched parameters
> are stored in the exchange later on - it's been assumed before that
> RequestHandlers would not need to deal with actual parameter
> values (or indeed with operations), rather they may want to affect the
> selection of operations by updating say the Accept value....
> But the moment users can get to the selected operation in filters but not
> to the actual values. I've fixed locally this issue by
> making sure matched parameters info is available - thus actually making it
> possible for the runtime to properly implement the
> injection of contexts like UriInfo into filtrers.
>
> Starting from 2.2.2, there's another option availbale - custom invokers -
> it will help you if you can move to 2.2.2 or 2.2.3 :
> http://cxf.apache.org/docs/jax-rs.html#JAX-RS-Custominvokers
>
> If you have to stay with 2.2.1 then you can do an another templates match
> (as you suggested), should not be really expensive:
>
> UriInfo uriInfo = new UriInfoImpl(message, null);
> OperationResourceInfo ori =
> message.getExchange().getContent(OperationResourceInfo.class);
> MultivaluedMap<String, String> map = new MetadataMap<String, String>();
> ori.getURITemplate().match(uriInfo.getPath(), map);
>
> In 2.2.4 you'll be able to do just this in the request handler :
>
> UriInfo uriInfo = new UriInfoImpl(message);
> uriInfo.getPathParameters();
>
> it's a new constructor which will extract the template values itself.
>
> Request and Response handlers will also have the injection working
> eventually for them like all other JAXRS providers.
>
> cheers, Sergey
>
> ----- Original Message -----
> From: "Kynan Fraser" <[email protected]>
> To: <[email protected]>
> Sent: Friday, September 04, 2009 6:10 AM
> Subject: Re: JAXRS - Best way to retrieve path parameters in request
> handler
>
>
>>
>> Hi Gabo,
>>
>> Thanks for the reply. Yes I had seen all these values but none quite fits
>> what i'm after.
>>
>> There's another set of info which is set after request handlers in the
>> JAXRSInInterceptor which is
>> message.get(URI_TEMPLATE.TEMPLATE_PARAMETERS), which contains the path
>> parameters in key/value pair.
>>
>> This info is built during the JAXRSUtil.findTargetMethod() call using
>> some
>> uriTemplate.match() calls etc.
>>
>> I'm really looking for the easiest way to either a) get than info in the
>> request handler f there's some nifty way of getting it or b) implementing
>> shortest way of getting it perhaps replicating the uriTemplate matching
>> ..
>>
>> Regards,
>> Kynan
>>
>>
>> Gabo Manuel wrote:
>>>
>>> Hi Kynan,
>>>
>>> I am not sure if this answers your question, I'll try:
>>>
>>> These are what I use for an inbound handler extending
>>> AbstractPhaseInterceptor<Message> at phase Phase.RECEIVE
>>>
>>> 1. message.get(Message.BASE_PATH) would give you the path
>>>
>>> 2. message.get(Message.QUERY_STRING) should give you everything on the
>>> right hand side of '?'. Since this would be a key-value pair, getting
>>> the name and value should be easy.
>>>
>>> 3. message.get(Message.REQUEST_URI) should give you the actual URI used.
>>> This would allow you to manually retrieve your path parameters. I am not
>>> sure how to retrieve the name assigned to that though.
>>>
>>> 4. message.get(Message.PROTOCOL_HEADERS) would give you all the Http
>>> headers, quite useful for authentication.
>>>
>>> Also, if everything you need is done by a specific interceptor, then
>>> maybe calling getAfter().add() at the constructor should cover it. :)
>>>
>>> Hth
>>>
>>> Gabo
>>>
>>> Kynan Fraser wrote:
>>>> Hi All,
>>>>
>>>> I'm writing a request handler which deals with the method going to be
>>>> invoked and the parameters provided (both query and path, both name and
>>>> value of each parameter). However i'm having some problem getting at
>>>> the
>>>> path paramter names and values - well I can ge the names but i need the
>>>> values too.
>>>>
>>>> It seems like the easiest way to get path paramters is to use
>>>> UriInfo(message) then getPathParameters(). But this requires the
>>>> URI_TEMPLATE.TEMPLATE_PARAMETERS to be set on the message to be used in
>>>> the
>>>> UriInfo constructor. This doesn't seem to be getting done until after
>>>> the
>>>> request handlers are called in the JAXRSInInterceptor.
>>>>
>>>> In CXF 2.2.1 - Request handlers are called on line 158 but the values
>>>> for
>>>> the URI_TEMPLATE.TEMPLATE_PARAMETERS are not set on the message until
>>>> line
>>>> 191.
>>>>
>>>> I figure I can always rerun findTargetMethod() or match the uri
>>>> template
>>>> and
>>>> populate it myself but thought there might be a way of getting this
>>>> which
>>>> is
>>>> better.
>>>>
>>>> Any tips?
>>>>
>>>> Thanks.
>>>> Kynan
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.409 / Virus Database: 270.13.76/2343 - Release Date:
>>>> 09/03/09 05:50:00
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JAXRS---Best-way-to-retrieve-path-parameters-in-request-handler-tp25287837p25288412.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context:
http://www.nabble.com/JAXRS---Best-way-to-retrieve-path-parameters-in-request-handler-tp25287837p25292023.html
Sent from the cxf-user mailing list archive at Nabble.com.
