cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rice Yeh <rice...@gmail.com>
Subject Re: [JAX-RS] request address extension mapping
Date Sat, 10 Jul 2010 03:11:04 GMT
After more tracking, I think the bug is on line 180 in
org.apache.cxf.jaxrs.model.URITemplate. The final group should be gotten by
the following statement:

 String finalGroup = m.group(m.groupCount());

The original statement fails because it does not assume uri template could
also contains group in it.

Regards,
Rice

On Sat, Jul 10, 2010 at 10:13 AM, Rice Yeh <riceyeh@gmail.com> wrote:

> Hi,
>   I traced the code to
> org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod method where the path
> is gotten from the final match group (line 284, see below). Based on the
> JAX-RS 1.0 spec, this is correct. However, on step 5 in 3.7.3 in JAX-RS
> spec, a ‘(/.*)?’ should be appended to the uri template. CXF seems missing
> this step and the final matching group becomes the address extension in my
> case.  Otherwise, it should be "".
>
> Regards,
> Rice
>
> String path = values.getFirst(URITemplate.FINAL_MATCH_GROUP);
>
>
> On Sat, Jul 10, 2010 at 4:26 AM, Sergey Beryozkin <sberyozkin@gmail.com>wrote:
>
>> Hi
>>
>> On Fri, Jul 9, 2010 at 10:29 AM, Rice Yeh <riceyeh@gmail.com> wrote:
>>
>> > Hi,
>> >  I have root resource class which match request's address extension. For
>> > example, htttp://localhost:8080/image/g1.png. The root resource class is
>> > successfully matched and then try to match the right method. However, in
>> > CXF, the path used to match to the methods is the extension "png". In
>> > Jboss's RESTEasy, it is the empty string "". I think the empty string is
>> > more correct.
>> >
>> > RestEasy is a good implementation all right :-)
>>
>>
>> >
>> > @Path("{resource:.+\\.(js|css|gif|png)}")
>> > public class PassThroughResource
>> > {
>> >
>> >    @GET
>> >    @Path("")
>> >    public InputStream get(@Context UriInfo uri) {
>> >    ...
>> >  }
>> > }
>> >
>> >
>> I'm presuming you debugged it - how did it happen that .gif was not
>> 'eaten'
>> by the above regular expression ?
>>
>> thanks, Sergey
>>
>>
>> > Regards,
>> > Rice
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message