> -----Original Message----- > From: John Klassa [mailto:[email protected]] > Sent: Wednesday, December 02, 2009 9:07 AM > To: [email protected] > Subject: "No operation matching request path" error > > [deleted] > > @Path("/bug") > public class DefectResource extends BaseResource > { > @GET > @Path("/{id}") > @Produces({"application/xml", "application/json"}) > public Response serveInfo (@PathParam("id") final String id, > @Context final UriInfo info) > > When I try to fetch a note with this URI, though: > > > /wsapi/v1/bug/SOMEBUGID/note/SOMENOTETITLE > > > I get: > > > No operation matching request path /SOMEBUGID/note/SOMENOTETITLE is > found > > The note code looks like this: > > @Path("/bug/{id}/note") > public class NoteResource extends BaseResource > { > @GET > @Path("/{name}") > @Produces("text/plain") > public Response serveContent (@PathParam("id") final String id, > @PathParam("name") final String name) >
I would be concerned about the fact that both resource classes begin with the same path prefix of "/bug". I doubt JAX-RS does any sort of algorithmic analysis to determine which resource class to use. It will likely just use the first one that matches the prefix. Try changing the prefix on "NoteResource" from "/bug" to "/note" (or something else) and test that. > What's odd about the error is that the actual address (as verified in > the logging interceptor) is, again: > > > /wsapi/v1/bug/SOMEBUGID/note/SOMENOTETITLE > > so I don't understand why it's trying to match from /SOMEBUGID/ onward, > rather than from /bug/ onward. > > What minor thing am I not seeing, here? :-) > > I've tried having note's serveContent() return String. I've also tried > having it Produce text/html (because that's what's in the Accept header > from the browser). In both cases, I thought maybe there was a content- > type mismatch of some sort. Doesn't appear to be the case... > > Thanks, > JK
