You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by John Klassa <jo...@klassa.com> on 2009/12/02 18:07:13 UTC
"No operation matching request path" error
I think I'm missing something obvious, but I can't figure out what it is.
I had some proof-of-concept code put together that does something just like this -- successfully -- but without Spring configuration (I was using an Application instance). I don't know if that's related, but thought I'd mention it. To the point, though, I was using the same @Path values in the code for my resources.
Anyway, in my beans.xml, I've got:
<jaxrs:server id="webServicesAPI" address="/">
<jaxrs:serviceBeans>
<ref bean="defectResourceBean"/>
<ref bean="noteResourceBean"/>
</jaxrs:serviceBeans>
<!-- other stuff -->
</jaxrs:server>
The defectResourceBean works perfectly... If I fetch:
> /wsapi/v1/bug/SOMEBUGID
I get nicely-formatted XML. The code for the defect resource starts out like this:
@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)
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
Re: "No operation matching request path" error
Posted by Sergey Beryozkin <sb...@progress.com>.
I just did a quick test and I can see a NoteResource is correctly selected...
Perhaps the HTTP Accept does not text/plain or wildcard ?
I have to go right now, will reply tomorrow
David, FYI, a selection algorithm specifies how to select between multiple matching classes, please see
http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-Selectingbetweenmultipleresourceclasses
though it might be outdated a bit
cheers, Sergey
----- Original Message -----
From: "KARR, DAVID (ATTCINW)" <dk...@att.com>
To: <us...@cxf.apache.org>
Sent: Wednesday, December 02, 2009 5:25 PM
Subject: RE: "No operation matching request path" error
> -----Original Message-----
> From: John Klassa [mailto:john@klassa.com]
> Sent: Wednesday, December 02, 2009 9:07 AM
> To: users@cxf.apache.org
> 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
RE: "No operation matching request path" error
Posted by "KARR, DAVID (ATTCINW)" <dk...@att.com>.
> -----Original Message-----
> From: John Klassa [mailto:john@klassa.com]
> Sent: Wednesday, December 02, 2009 9:07 AM
> To: users@cxf.apache.org
> 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