Hi Sergey, This is server-side, so using the Method approach appears to be the solution. Thanks!
JK On Oct 8, 2010, at 12:10 PM, Sergey Beryozkin wrote: > Hi John > > Unfortunately it is not possible for UriBuilder(Impl) to guess that given 3 > path() invocations a corresponding method @Path value has to be used... > > By the way, on what context do you use UriBuilder to create this URI ? > If you are building a URI on the client side for consuming the project > resource and would like to worry only about individual values and not to be > concerned about how those values are positioned in the URI path then proxies > are the best bet. In other cases you need to be explicit and either specify > a Method so that URIBuilder can get the path from it or just specify "-" > directly > > cheers, Sergey > > On Fri, Oct 8, 2010 at 3:58 PM, John Klassa <[email protected]> wrote: > >> >> Hi Sergey, >> >> I think I've got it figured out... Using one of the examples in the >> documentation, I finally arrived at something like this: >> >>> UriBuilder ub = info.getBaseUriBuilder().path(ProjectResource.class); >>> >>> return ub.path(ProjectResource.class, "handleTransition") >>> .build(type, name, state, target).toString(); >> >> which seems to do it. Basically, I stopped using overloaded resource >> method names, and then also picked one explicitly in/for the construction of >> the URI. >> >> When I do something like this (without an explicit choice of method): >> >>> UriBuilder ub = info.getBaseUriBuilder().path(ProjectResource.class); >>> >> >>> return >> ub.path(type).path(name).path(state).path(target).build().toString(); >> >> I get a result with "/" everywhere, including in the last position where a >> "-" should be. I only have one resource method that has four parameters -- >> and it's the one with a "-" in it -- so I'd have thought this would work, >> too. >> >> Thanks, >> JK >> >> On Oct 7, 2010, at 6:27 PM, Sergey Beryozkin wrote: >> >>> Hi John >>> thanks for this example... >>> >>> >>> On Thu, Oct 7, 2010 at 10:57 PM, John Klassa <[email protected]> wrote: >>> >>>> >>>> I'm trying to build a URI in code, using features of CXF. My resource >>>> class and methods are annotated thusly: >>>> >>>> @Path("/project") >>>> public class ProjectResource >>>> // ... >>>> @GET >>>> @Path("/{type}/{name}") >>>> public Response serveContent (...) >>>> @GET >>>> @Path("/{type}/{name}/{state}") >>>> @Produces({"text/plain", "application/xml", "application/json"}) >>>> public Response serveContent (...) >>>> @GET >>>> @Path("/{type}/{name}/{state}-{target}") >>>> public Response serveContent (...) >>>> >>>> Basically, you've got a "project" which has a "type" and a "name", and >> then >>>> you might want info about: >>>> >>>> 1. the project as a whole: /project/mytype/myproj >>>> 2. a state within the project: /project/mytype/myproj/mystate >>>> 3. a state transition within the project: >>>> /project/mytype/myproj/mystate0-mystate1 >>>> >>>> [Note that I chose to model #3 as "old-new" rather than "old/new" >> because >>>> there isn't really a hierarchy here; it's more that the transition >> itself is >>>> a resource, and so joining the pieces with a "-" seemed more natural.] >>>> >>>> To that end, when I attempt to construct a URI for a particular resource >>>> (in order to put a link to it inside some other resource, for example), >> CXF >>>> seems to want to build a generic URI out of my path components, using >>>> slashes as the separator. It never inserts the dash, even in the event >> that >>>> enough parameters have been specified to warrant one. >>>> >>>> Am I misunderstanding the functionality here? Should it be possible to >>>> have CXF construct a URI from the best-matching pattern in a resource >> method >>>> annotation? That is, if I pass values into some variant of: >>>> >>>> UriBuilder >>>> .fromResource(SomeResource.class) >>>> .path(xxx) >>>> .build(yyy) >>>> >>>> should it be possible to get a URI that has the dash in it, in my case? >>>> >>>> >>> it should definitely work, what values do you provide for path(...) ? >>> >>> cheers, Sergey >> >>
