> -----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. > >
