1

I found something similar here but not the same as my problem.


I am building an Apache Wink application and I have a resource class like this..

@Path("/things")
@Produces(MediaType.APPLICATION_JSON + ";charset=UTF-8")
public class ThingResource extends AbstractResource {
  ...
}


My first GET method is intended to be the basic get-collection method that is called in response to ... www.example.com/context/things. It looks like the following

@GET
public List <Thing> getThings() {
  ...
}


My second GET method is supposed to get a specific Thing returned by getThings(), it looks like the below

@GET
@Path("/{thingId}")
public Thing getThing (@PathParam ("thingId") long id) {
 ...
}

Up to this point, everything is working just fine.

So, when I add another GET method, intended to create a file representation of a specific Thing from the collection returned by the getThings() -- (It is as below) -- I get a 404 error when I try to hit the [get /] => getThings()

@GET
@Path("/{thingId}/export")
public javax.ws.rs.core.Response exportThing( @PathParam ("thingId") long thingId, @DefaultValue("true") boolean encryptFile) {
  ...
}


If I remove the exportThing() method and redeploy it, it runs fine.

Tomcat 6 Java 6 Apache Wink 1.2

Community
  • 1
  • 1
rogodeter
  • 460
  • 9
  • 19
  • 3
    You have an extra parameter in your `exportThing`, with a 'dangling' @DefaultValue annotation. I'd remove those. – Perception Feb 23 '13 at 06:53
  • Must the params (qty) match the path? My intention was that the thingId would be passed in (required), the string "/export" would follow, and the encryptFile would be optional. Can I handle that optional case or should I overload exportThings() with URI Patterns that exactly match the method sig? `@GET @Path("/{thingId}/export") public Response exportThing(@PathParam("thingId") long thingId ) { ... }` --- `@GET @Path("/{thingId}/export/{encryptFile}") public Response exportThing(@PathParam("thingId") long thingId, @PathParam("encryptFile") boolean encryptFile ) { ... }` – rogodeter Feb 23 '13 at 17:01
  • 3
    Yes, use the override strategy. Your current method doesn't do what you think it does (it maps the @PathParam, then attempts to deserialize the request body into the `encryptFile` parameter). – Perception Feb 23 '13 at 17:11
  • You had it right @Perception, I refactored it and it works fine now. – rogodeter Feb 25 '13 at 17:28

0 Answers0