You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by asookazian <as...@gmail.com> on 2016/05/10 22:27:35 UTC

Re: No operation matching request path...

cxf 3.0.4 running on karaf 3.0.3

Getting same error as OP, here is the logging output:

2016-05-10 15:01:41,566 | WARN  | qtp293687425-73  | JAXRSUtils                      
| 191 - org.apache.cxf.cxf-rt-frontend-jaxrs - 3.0.4 | No operation matching
request path "/ws/mm/er/arbitest" is found, Relative Path: /, HTTP Method:
GET, ContentType: */*, Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. Please
enable FINE/TRACE log level for more details.
2016-05-10 15:01:41,567 | WARN  | qtp293687425-73  |
WebApplicationExceptionMapper    | 191 -
org.apache.cxf.cxf-rt-frontend-jaxrs - 3.0.4 |
javax.ws.rs.ClientErrorException: HTTP 404 Not Found
	at
org.apache.cxf.jaxrs.utils.SpecExceptions.toHttpException(SpecExceptions.java:117)
	at
org.apache.cxf.jaxrs.utils.ExceptionUtils.toHttpException(ExceptionUtils.java:166)
	at
org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:529)
	at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:177)
	at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
	at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
	at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
	at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
	at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
	at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
	at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
	at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:217)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
	at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
	at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:503)
	at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
	at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
	at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
	at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
	at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
	at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
	at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
	at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
	at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
	at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
	at
org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
	at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
	at org.eclipse.jetty.server.Server.handle(Server.java:370)
	at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
	at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)
	at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
	at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
	at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
	at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
	at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
	at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
	at java.lang.Thread.run(Thread.java:745)

Here is the GET: http://localhost:8181/ws/mm/er/arbitest

Here is the pertinent portion from the WADL:

<resource path="/arbitest"><method name="GET"><response><representation
mediaType="application/json"/></response></method></resource>

karaf ()> cxf:list-endpoints | grep "/mm/er"
[MyRestService] [Started ] [/mm/er                                                   
] [com.foo.bar.rest-cxf1046709550]

What is the reason why I am getting this error for this new endpoint, it is
unexpected as I've checked the paths match, it looks correct.  Also, I have
another new public method in this REST service class that is reproducing
same error (404).  Other pre-existing REST endpoints are working as
expected.  thx.



--
View this message in context: http://cxf.547215.n5.nabble.com/No-operation-matching-request-path-tp556149p5768521.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: No operation matching request path...

Posted by Sergey Beryozkin <sb...@gmail.com>.
Yes, it is supported.
Starting from 3.1.x, JAX-RS 2.0 matching at the class resource level is 
properly supported for cases where multiple class resources have the 
identical Path value, was too sensitive to address it for 3.0.x.
Other than that, if multiple class resources have different path values 
then the class resource which wins will be considered further for the 
actual method, no backtracking will be made...

Sergey
On 11/05/16 19:36, asookazian wrote:
> so the new jaxrs:servicebean class endpoints are now working.  previously
> they were configure as a ref/component on the same address as the existing
> service/class (which apparently is illegal but I saw no exception in the log
> when i updated the bundle in karaf).
>
> the existing BP config.xml has the same issue:
>
> <jaxrs:server id="EventRegistryRS" address="/mm/er">
>          <jaxrs:serviceBeans>
>              <ref component-id="foo"/>
>              <ref component-id="bar"/>
>          </jaxrs:serviceBeans>
>          <jaxrs:providers>
>              <ref component-id="filter1"/>
>              <ref component-id="provider1"/>
>              <ref component-id="provider2"/>
>          </jaxrs:providers>
>      </jaxrs:server>
>
> foo extends bar in this case.  the existing methods/endpoints for that
> original class/service are working.  when I add the new methods, they show
> up in the WADL but I get 404 on GET requests.
>
> is it legal/ok to list more than one component in the <jaxrs:serviceBeans>
> section above?  How does cxf know which class to route to based on that
> particular address?
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/No-operation-matching-request-path-tp556149p5768585.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: No operation matching request path...

Posted by asookazian <as...@gmail.com>.
Problem solved, in the extending class (not previously shown in thread),
there was a regex in the @Path for the root elements in the endopint URIs
and I had added 2 methods/endpoints both of which had previously unlisted
elements in the regex for @Path.



--
View this message in context: http://cxf.547215.n5.nabble.com/No-operation-matching-request-path-tp556149p5768586.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: No operation matching request path...

Posted by asookazian <as...@gmail.com>.
so the new jaxrs:servicebean class endpoints are now working.  previously
they were configure as a ref/component on the same address as the existing
service/class (which apparently is illegal but I saw no exception in the log
when i updated the bundle in karaf).

the existing BP config.xml has the same issue:

<jaxrs:server id="EventRegistryRS" address="/mm/er">
        <jaxrs:serviceBeans>
            <ref component-id="foo"/>
            <ref component-id="bar"/>
        </jaxrs:serviceBeans>
        <jaxrs:providers>
            <ref component-id="filter1"/>
            <ref component-id="provider1"/>
            <ref component-id="provider2"/>
        </jaxrs:providers>
    </jaxrs:server>

foo extends bar in this case.  the existing methods/endpoints for that
original class/service are working.  when I add the new methods, they show
up in the WADL but I get 404 on GET requests.

is it legal/ok to list more than one component in the <jaxrs:serviceBeans>
section above?  How does cxf know which class to route to based on that
particular address?



--
View this message in context: http://cxf.547215.n5.nabble.com/No-operation-matching-request-path-tp556149p5768585.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: No operation matching request path...

Posted by asookazian <as...@gmail.com>.
@GET @Path("/arbitest") @Produces({MediaType.APPLICATION_JSON})
    public Map<String, Map&lt;List&lt;String>, Set<Map&lt;String,Object>>>>
getArbitest() {
    	LOG.trace("in getArbitest()");
    	Map<String, Map&lt;List&lt;String>, Set<Map&lt;String,Object>>>> map =
new HashMap<>();
    	return map;
    }

I've also tried writing a new jax-rs service class with public methods and
none of those methods are showing up in the WADL, not sure why as I've
updated the blueprint config.xml accordingly with the appropriate new jaxrs
serviceBean.

When/how is the WADL generated?  When this GET request is executed?

http://localhost:8181/ws/mm/er/er?_wadl

I have updated the OSGi bundle for rest bundle and even restarted Karaf,
still doesn't show the new methods from the new jaxrs service class.

btw, for both jaxrs service classes, the following is annotated at the class
level:

@Path("/")



--
View this message in context: http://cxf.547215.n5.nabble.com/No-operation-matching-request-path-tp556149p5768584.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: No operation matching request path...

Posted by Sergey Beryozkin <sb...@gmail.com>.
Can you type a sample resource class/service method with the relevant 
annotations ?

Thanks
On 10/05/16 23:27, asookazian wrote:
> cxf 3.0.4 running on karaf 3.0.3
>
> Getting same error as OP, here is the logging output:
>
> 2016-05-10 15:01:41,566 | WARN  | qtp293687425-73  | JAXRSUtils
> | 191 - org.apache.cxf.cxf-rt-frontend-jaxrs - 3.0.4 | No operation matching
> request path "/ws/mm/er/arbitest" is found, Relative Path: /, HTTP Method:
> GET, ContentType: */*, Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,. Please
> enable FINE/TRACE log level for more details.
> 2016-05-10 15:01:41,567 | WARN  | qtp293687425-73  |
> WebApplicationExceptionMapper    | 191 -
> org.apache.cxf.cxf-rt-frontend-jaxrs - 3.0.4 |
> javax.ws.rs.ClientErrorException: HTTP 404 Not Found
> 	at
> org.apache.cxf.jaxrs.utils.SpecExceptions.toHttpException(SpecExceptions.java:117)
> 	at
> org.apache.cxf.jaxrs.utils.ExceptionUtils.toHttpException(ExceptionUtils.java:166)
> 	at
> org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:529)
> 	at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSInInterceptor.java:177)
> 	at
> org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInInterceptor.java:77)
> 	at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> 	at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> 	at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:251)
> 	at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> 	at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> 	at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> 	at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)
> 	at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:293)
> 	at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:217)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
> 	at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:268)
> 	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
> 	at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:503)
> 	at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)
> 	at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> 	at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> 	at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> 	at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
> 	at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)
> 	at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
> 	at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> 	at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
> 	at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> 	at
> org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:75)
> 	at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> 	at org.eclipse.jetty.server.Server.handle(Server.java:370)
> 	at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
> 	at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)
> 	at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)
> 	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
> 	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> 	at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> 	at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
> 	at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
> 	at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> 	at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> 	at java.lang.Thread.run(Thread.java:745)
>
> Here is the GET: http://localhost:8181/ws/mm/er/arbitest
>
> Here is the pertinent portion from the WADL:
>
> <resource path="/arbitest"><method name="GET"><response><representation
> mediaType="application/json"/></response></method></resource>
>
> karaf ()> cxf:list-endpoints | grep "/mm/er"
> [MyRestService] [Started ] [/mm/er
> ] [com.foo.bar.rest-cxf1046709550]
>
> What is the reason why I am getting this error for this new endpoint, it is
> unexpected as I've checked the paths match, it looks correct.  Also, I have
> another new public method in this REST service class that is reproducing
> same error (404).  Other pre-existing REST endpoints are working as
> expected.  thx.
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/No-operation-matching-request-path-tp556149p5768521.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/