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().get("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()
Cheers, Sergey
