Hi
On 18/01/13 20:21, Clint Dovholuk wrote:
Fantastic Sergey! I am not in love with PathSegment vs String that's just a
snippet I think I found on the apache site that I used for whatever reason.
String makes perfect sense to me.
PathSegment can be handy when matrix parameters are also there, it is
just it is not easy to use it on the client side directly - though CXF
specific utility class is available
When would the next rev of the versions come out? For now I can just use a
snapshot to test it out but is there a release schedule or is it just released
when it's ready?
It will likely be a while (5 weeks or so) before next CXF2.6.x/2.7.x
gets released, so in meantime please try the snapshots
Thanks, Sergey
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Friday, January 18, 2013 11:46 AM
To: [email protected]
Subject: Re: wadl2java issue with wildcards - supported?
Hi Clint
I've got this resolved on trunk and all the branches, thanks for reporting this
issue.
Note the code generator generates "List<String>" instead of
"List<PathSegment>", path segment is supposed to capture the path values and matrix parameters,
but in WADL these parameters are provided separately.
May be you can just use "String" and then do a basic "/" split to get a list of
path values
Cheers, Sergey
On 16/01/13 15:06, Clint Dovholuk wrote:
Hi Sergey,
I had tried that as well but the regex still persists
@POST
@Path("/{search:.*}")
String postSearch:.*(@PathParam("search") List<String> search);
Thanks!
-Clint
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Wednesday, January 16, 2013 8:50 AM
To: [email protected]
Subject: Re: wadl2java issue with wildcards - supported?
Hi
On 16/01/13 01:37, Clint Dovholuk wrote:
Hi all,
I have been trying to get cxf to consume a wadl (which is produced by me using
cxf v2.5.1). The service has a method defined like this:
@Path("/{search:.*}")
@POST
public String testing(@PathParam("search") List<PathSegment>
searchList)
When the wadl is generated it pops out this definition:
<resource path="{search:.*}">
<param name="search" style="template" repeating="true"/>
<method name="POST">
When this is consumed by cxf version> 2.5.3 it emits a java class that won't
compile:
@Path("/{search:.*}")
String postSearch:.*(@PathParam("search") List<String> search);
//notice that this won't compile ;)
When I consume the same wadl with cxf 2.5.1 - 2.5.3 it produces this definition
which at least compiles:
@Path("{search:.*}")
String post(@PathParam("search") List<String> search);
I've tried to search for this on the internet but it's just a bear to find
anything relevant. Any help would be appreciated.
This regression was a side-effect of the fix to do with ensuring that WADLs with no
method "id" attributes have methods with the same HTTP verb not conflicting at
the Java source level, but obviously we need to strip the reg-ex bit from the actual Path
value - thanks for reporting it.
In meantime, please try registering WADLGenerator explicitly (as
jaxrs:provider) and enable its 'addResourceAndMethodIds' property -
that should add ids to the auto-generated methods and make the code
generation working
Thanks, Sergey
Thanks
-Clint
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
