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
