Great. JAX-RS 2.0 has started and who knows may be UriBuilder can get enhanced a bit. It has a replacePath method but it replaces everything accumulated so far.
so returning an unmodifiable list of existing segments and adding another replacePath overriding the last or specific segment only with a new value can be handly. Actually, WebClient now has replacePath too and it can be used to replace either the whole path or the last segment only, so something similar may be added in principle to UriBuilder Sergey On Wed, Apr 27, 2011 at 5:15 PM, KARR, DAVID (ATTSI) <[email protected]> wrote: >> -----Original Message----- >> From: Sergey Beryozkin [mailto:[email protected]] >> Sent: Wednesday, April 27, 2011 8:40 AM >> To: [email protected] >> Subject: Re: How to append file extent to end of path, before query >> parameters? >> >> I thought the problem was that you were concatenating a String >> representation of Method with the extension value. >> What happens when you pass a Method reference to UriBuilder is that >> internally a @Path annotation and its value is checked. So I thought >> this is what you could yourself, cache @Path values instead of Method >> refs and concatenate them with the extensions > > This strategy works. It's likely even a smidge faster, as the other method > would have to get the @Path annotation value anyway. > >> On Wed, Apr 27, 2011 at 4:32 PM, KARR, DAVID (ATTSI) <[email protected]> >> wrote: >> >> -----Original Message----- >> >> From: Sergey Beryozkin [mailto:[email protected]] >> >> Sent: Wednesday, April 27, 2011 8:26 AM >> >> To: [email protected] >> >> Subject: Re: How to append file extent to end of path, before query >> >> parameters? >> >> >> >> Hi >> >> >> >> >> The following should work then : >> >> >> >> >> >> .path(getMethodMap().get("getStuff") + buildFileExtent()); >> >> > >> >> > Hmm, that produced a different problem. >> >> > >> >> > The first line in the old code looks something like this: >> >> > >> >> > UriBuilder builder = >> >> > >> >> >> getUriInfo().getBaseUriBuilder().path(getClass()).path(getMethodMap(). >> >> get("stuff")); >> >> > >> >> > With the old code, after the initial construction of the Builder, >> the >> >> "paths" list in the debugger view showed approximately this: >> >> > >> >> > [stuff, {productId}, {zip}] >> >> > >> >> > After putting in arguments (appending the extent manually to the >> >> zip), I ended up with approximately this: >> >> > >> >> > http://localhost:9000/service/rest/junk/stuff/1/98077.en- >> >> us.json?somearg=value >> >> > >> >> > This is fine, except for the inconvenience of how I have to add >> the >> >> extent. >> >> > >> >> > I then followed your suggestion and changed the first line to this >> >> (removing "buildFileExtent()" from the later code to add the >> >> arguments): >> >> > >> >> > UriBuilder builder = >> >> >> getUriInfo().getBaseUriBuilder().path(getClass()).path(getMethodMap().g >> >> et("stuff") + buildFileExtent()); >> >> > >> >> > After this line, instead of the previous array value, the "paths" >> >> list was now this: >> >> > >> >> > [public mypackage.GetStuffResponse >> >> >> mypackage.Controller.getStuff(java.lang.String,java.lang.String,boolean >> >> ,java.lang.String).en-us.json] >> >> > >> >> > So, it's obvious that just appending a string to the end of a >> method >> >> signature string confuses the "path()" method. I'm guessing it used >> >> that signature to get the "@Path" annotation somehow, so when the >> >> signature was corrupted, it couldn't find it, so it punted. >> >> > >> >> >> >> I guess this is because getMethodMap().get("stuff") returns a Method >> >> reference. May be you can cache @Path values, you can get them from >> >> Method or Class like this : >> >> >> >> method.getAnnotation(Path.class).value() >> > >> > I don't get what I would do with that. >> > >> > It seems to me UriBuilder is just missing the functionality to be >> able to do this cleanly. I'd say the following would be useful: >> > * Direct access to the computed path segments (which is already >> available in UriBuilderImpl), so I could just append to the last one >> > * A "appendToComputedPath(String)" (or something like that) method. >> > >
