Hi Sergey,
Thanks, second option works:
OperationResourceInfo ori =
message.getExchange().getContent(OperationResourceInfo.class);
URITemplate t1 = ori.getClassResourceInfo().getURITemplate();;
URITemplate t2 = ori.getURITemplate();
MultivaluedMap<String, String> map = new MetadataMap<String, String>();
t1.match(uriInfo.getPath(), map);
t2.match(map.get(URITemplate.FINAL_MATCH_GROUP), map);
Regards,
Kynan
Sergey Beryozkin wrote:
>
> Hi Kynan
>
> You can probably do
>
> OperationResourceInfo ori =
> message.getExchange().getContent(OperationResourceInfo.class);
> URITemplate t1 = ori.getClassResourceInfo().getURITemplate();;
> URITemplate t2 = ori.getURITemplate();
>
> MultivaluedMap<String, String> map = new MetadataMap<String, String>();
>
> URITemplate.createTemplate(t1.getValue() +
> t2.getValue()).match(uriInfo.getPath(), map);
>
> or
>
> t1.match(uriInfo.getPath(), map);
> t2.match(map.get(URITemplate.FINAL_MATCH_GROUP), map);
>
> hope you won't have to do it starting from 2.2.4 :-)
>
> cheers, Sergey
>
>
> Kynan Fraser wrote:
>>
>> Hi Sergey,
>>
>> Just found an issue with this matching - if a class level resource has a
>> path parameter in it then the operation resource info won't
>> return/contain that.
>>
>> ie.
>> @Path("/something/{id}/more")
>> public class classA{
>>
>> @Path("/details/{idx}/")
>> public void methodB(){
>> }
>> }
>>
>> Then this:
>>
>> 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);
>>
>> will not contain the first {id} param because its an operation level
>> object not class level. Alternatively if i use the ClassResourceInfo for
>> matching, I won't get method level PathParam's.
>>
>> Is there a way in a request handler to match against the entire path or
>> is this not possible?
>>
>> Regards,
>> Kynan
>>
>>
>> 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" <kynan.fra...@customware.net>
>>> To: <users@cxf.apache.org>
>>> 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-tp25287837p25463934.html
Sent from the cxf-user mailing list archive at Nabble.com.
