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