You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Veit Guna <Ve...@gmx.de> on 2015/04/23 09:37:09 UTC

@Path with regex not working correctly on client side

Hi.
 
I'm using @Path annotations on SubResourceLocators for my REST interfaces using regexs.
For the client side, I'm using the Apache CXF (3.0.4) proxied server interfaces and it works so far - except with @Path's that contain regex.
As a result, a BAD_REQUEST is returned to the client. Example for such an annotation:
 
@Path("{repositoryEntryId : .+(?<!\\/content) }")

Looking at the generated URL on the client proxy shows:

...someurlpart/%7BrepositoryEntryId%20:%20.+(%3F%3C!%5C/content)%20%7D

So it seems that on client side, the @Path param isn't correctly recognized due to the regex format.
Is this a known issue?

Thanks
Veit

Re: @Path with regex not working correctly on client side

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi

Surprise, it does not work because a regular expression itself contains 
a forward slash :-)

URI newUri = new 
UriBuilder.fromUri("http://bar").path("{repositoryEntryId : .+ 
}").build("1");

produces "http://bar/1".

Looks like the implementation of CXF UriBuilder needs to be fixed to 
make a proper parsing of a provided path value (which may have multiple 
path segments with multiple '/' values), but I honestly not sure right 
now how easy/sensitive that might be given that this '/' is inside a 
template declaration.

Can you try and make a simpler regular expression as a workaround for 
now ? I will investigate in meantime and see how a more complex 
expression with "/" cam also be supported

Thanks, Sergey

On 23/04/15 12:45, Sergey Beryozkin wrote:
> Hi
>
> Indeed having the regular expression encoded is wrong. See it is all
> delegated to a UriBuilder and doing
>
> URI newUri = new
> UriBuilder.fromUri("http://bar").path("{repositoryEntryId :
> .+(?<!\\/content) }").build("1");
>
> does not produce "http://bar/1"
>
> I've actually never seen such an example where a builder is initialized
> with a template containing a regular expression. In this case UriBuilder
> does not fail which means it does recognize 'repositoryEntryId' as a
> template var but somehow it still uses the actual template expression as
> a path value...
>
> Looks like UriBulder needs a fix, will have a look
>
> Cheers, Sergey...
> On 23/04/15 08:37, Veit Guna wrote:
>> Hi.
>>
>> I'm using @Path annotations on SubResourceLocators for my REST
>> interfaces using regexs.
>> For the client side, I'm using the Apache CXF (3.0.4) proxied server
>> interfaces and it works so far - except with @Path's that contain regex.
>> As a result, a BAD_REQUEST is returned to the client. Example for such
>> an annotation:
>>
>> @Path("{repositoryEntryId : .+(?<!\\/content) }")
>>
>> Looking at the generated URL on the client proxy shows:
>>
>> ...someurlpart/%7BrepositoryEntryId%20:%20.+(%3F%3C!%5C/content)%20%7D
>>
>> So it seems that on client side, the @Path param isn't correctly
>> recognized due to the regex format.
>> Is this a known issue?
>>
>> Thanks
>> Veit
>>
>


Re: @Path with regex not working correctly on client side

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi

Indeed having the regular expression encoded is wrong. See it is all 
delegated to a UriBuilder and doing

URI newUri = new 
UriBuilder.fromUri("http://bar").path("{repositoryEntryId : 
.+(?<!\\/content) }").build("1");

does not produce "http://bar/1"

I've actually never seen such an example where a builder is initialized 
with a template containing a regular expression. In this case UriBuilder 
does not fail which means it does recognize 'repositoryEntryId' as a 
template var but somehow it still uses the actual template expression as 
a path value...

Looks like UriBulder needs a fix, will have a look

Cheers, Sergey...
On 23/04/15 08:37, Veit Guna wrote:
> Hi.
>
> I'm using @Path annotations on SubResourceLocators for my REST interfaces using regexs.
> For the client side, I'm using the Apache CXF (3.0.4) proxied server interfaces and it works so far - except with @Path's that contain regex.
> As a result, a BAD_REQUEST is returned to the client. Example for such an annotation:
>
> @Path("{repositoryEntryId : .+(?<!\\/content) }")
>
> Looking at the generated URL on the client proxy shows:
>
> ...someurlpart/%7BrepositoryEntryId%20:%20.+(%3F%3C!%5C/content)%20%7D
>
> So it seems that on client side, the @Path param isn't correctly recognized due to the regex format.
> Is this a known issue?
>
> Thanks
> Veit
>