You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gabo Manuel <km...@solegysystems.com> on 2009/02/18 09:02:07 UTC
[JAXRS][IE] subresource locator feature getting confused
Hi All,
I was testing the web service I have created and it works without a
hitch when using HttpClient as ... well client. However, if I use I.E.
to check (haven't tested fire fox or any browser yet), I encounter the
following error:
javax.ws.rs.WebApplicationException
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:295)
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:161)
at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:67)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:305)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:138)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:163)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:145)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Then I receive a runtime exception client side. What I find weird is
that a method was properly invoked. More specifically, the subresource
locator was used. There are two methods defined and annotated as follows:
@Consumes("*/*")
@Produces("text/xml")
@Path("/Objects")
public class ObjectService{
@GET
@Path("/")
@WebMethod
public Object getObject(
@QueryParam("id")
@WebParam(name="id")
long id) {
//this is the method that I was invoking... supposedly
logger.info("get Object received: " + id);//Note this
return new MyObject();
}
@Path("/")
@WebMethod(exclude=true)
public Object getObjectProperty(
@QueryParam("id")
@WebParam(name="id")
long id) {
//this got invoked ... but should not have been
logger.info("get Object Property received: " + id);//Note this
return getObject(id);
}
}
@XmlType(name="MyObject")
@XmlAccessorType(XmlAccessType.PROPERTY)
@XmlRootElement(name="MyObject")
public class MyObject {
@GET
@Path("/field1")
public String getField1() {
return "field1";
}
public void setField1() {
}
}
The debug log shows the following:
2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object Property received: 1
2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object received: 1
I am assuming it is having a problem finding the subresource since
technically, it shouldn't even be the method being invoked. URL being
used is:
http://localhost:8080/cxf/Objects/?id=1
I am not sure if it helps but maybe the extra headers affects this?
These are not received when HttpClient is used.
accept-language=[en-us], user-agent=[Mozilla/4.0 (compatible; MSIE 7.0;
Windows NT 5.1)], accept-encoding=[gzip, deflate], ua-cpu=[x86],
Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, */*]
I am using the following:
tomcat 6.0.13
java 1.6
cxf 2.2-snapshot (Jan 27)
Thanks in advance.
Gabo
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Sorry for the late reply. I have just tested 2.2.1 and it works for both
IE and firefox. Thanks again!
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>>
>> > Either way, I'll get it fixed for 2.2 (the issue highlighted by your
>> original example)
>>
>> Not in a rush. :) I doubt the client is going to use I.E. anyway. :D
>
> Fingers crossed, oyt should be fixed now. I have a test matching your
> scenario. I'll still be tweaking few things around the way accept
> types are handled, but the test will protect again the regression.
>
> If you could try and confirm it with a trunk (mvn install
> -Pfastinstall, cd api, mvn install, cd distribution, mvn install, get
> the cxf-distribution out of distribution/target) in the next couple of
> weeks then it would be good
>
> Cheers, Sergey
>
>>
>> Thanks.
>>
>> Gabo
>>
>> Sergey Beryozkin wrote:
>>> Hi Gabo
>>>
>>> I believe in your original post getObjects() had @Path("/"), right ?
>>> In this last example the IE requests should be fine. What I meant
>>> was something like this :
>>>
>>>> @GET
>>>> @Path("/get")
>>>> @WebMethod
>>>> public MyObjects getObjects(){
>>>> }
>>>>
>>>> @GET
>>>> @Path("/get/")
>>>> @WebMethod
>>>> public Object getObject( @QueryParam("id")
>>>> @WebParam(name="id")
>>>> long id) {
>>>> }
>>>
>>> in which case /get?id=1 will be delivered to getObject(), while
>>> /get/foo?id=1 /get/bar?id=1 or will be delivered to
>>> getObjectProperty...
>>>
>>> but it might not be acceptable for your specific case. Either way,
>>> I'll get it fixed for 2.2 (the issue highlighted by your original
>>> example)
>>>
>>> Cheers, Sergey
>>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.237 / Virus Database: 270.11.3/1974 - Release Date: 02/26/09 14:51:00
>
>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Sorry for the late reply. I have just tested 2.2.1 and it works for both
IE and firefox. Thanks again!
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>>
>> > Either way, I'll get it fixed for 2.2 (the issue highlighted by your
>> original example)
>>
>> Not in a rush. :) I doubt the client is going to use I.E. anyway. :D
>
> Fingers crossed, oyt should be fixed now. I have a test matching your
> scenario. I'll still be tweaking few things around the way accept
> types are handled, but the test will protect again the regression.
>
> If you could try and confirm it with a trunk (mvn install
> -Pfastinstall, cd api, mvn install, cd distribution, mvn install, get
> the cxf-distribution out of distribution/target) in the next couple of
> weeks then it would be good
>
> Cheers, Sergey
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
>
> > Either way, I'll get it fixed for 2.2 (the issue highlighted by your
> original example)
>
> Not in a rush. :) I doubt the client is going to use I.E. anyway. :D
Fingers crossed, oyt should be fixed now. I have a test matching your scenario. I'll still be tweaking few things around the way
accept types are handled, but the test will protect again the regression.
If you could try and confirm it with a trunk (mvn install -Pfastinstall, cd api, mvn install, cd distribution, mvn install, get the
cxf-distribution out of distribution/target) in the next couple of weeks then it would be good
Cheers, Sergey
>
> Thanks.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> I believe in your original post getObjects() had @Path("/"), right ?
>> In this last example the IE requests should be fine. What I meant was something like this :
>>
>>> @GET
>>> @Path("/get")
>>> @WebMethod
>>> public MyObjects getObjects(){
>>> }
>>>
>>> @GET
>>> @Path("/get/")
>>> @WebMethod
>>> public Object getObject( @QueryParam("id")
>>> @WebParam(name="id")
>>> long id) {
>>> }
>>
>> in which case /get?id=1 will be delivered to getObject(), while /get/foo?id=1 /get/bar?id=1 or will be delivered to
>> getObjectProperty...
>>
>> but it might not be acceptable for your specific case. Either way, I'll get it fixed for 2.2 (the issue highlighted by your
>> original example)
>>
>> Cheers, Sergey
>>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
> I believe in your original post getObjects() had @Path("/"), right ?
Yes. I have three methods all in all
"/" maps to getObject (an individual record) and getObjectProperty (an
individual property of the record)
"/search/" maps to getObjects (a list of records)
> Either way, I'll get it fixed for 2.2 (the issue highlighted by your
original example)
Not in a rush. :) I doubt the client is going to use I.E. anyway. :D
Thanks.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> I believe in your original post getObjects() had @Path("/"), right ?
> In this last example the IE requests should be fine. What I meant was
> something like this :
>
>> @GET
>> @Path("/get")
>> @WebMethod
>> public MyObjects getObjects(){
>> }
>>
>> @GET
>> @Path("/get/")
>> @WebMethod
>> public Object getObject( @QueryParam("id")
>> @WebParam(name="id")
>> long id) {
>> }
>
> in which case /get?id=1 will be delivered to getObject(), while
> /get/foo?id=1 /get/bar?id=1 or will be delivered to getObjectProperty...
>
> but it might not be acceptable for your specific case. Either way,
> I'll get it fixed for 2.2 (the issue highlighted by your original
> example)
>
> Cheers, Sergey
>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
I believe in your original post getObjects() had @Path("/"), right ?
In this last example the IE requests should be fine. What I meant was something like this :
> @GET
> @Path("/get")
> @WebMethod
> public MyObjects getObjects(){
> }
>
> @GET
> @Path("/get/")
> @WebMethod
> public Object getObject( @QueryParam("id")
> @WebParam(name="id")
> long id) {
> }
in which case /get?id=1 will be delivered to getObject(), while /get/foo?id=1 /get/bar?id=1 or will be delivered to
getObjectProperty...
but it might not be acceptable for your specific case. Either way, I'll get it fixed for 2.2 (the issue highlighted by your original
example)
Cheers, Sergey
> Hi Sergey,
>
> Let me clarify that
>
> Given:
> @GET
> @Path("/search/")
> @WebMethod
> public MyObjects getObjects(){
> //this is the method that I was invoking... supposedly
> //using a list wrapper as advised in the user's guide
> return new MyObjects(new MyObject());
> }
>
> @GET
> @Path("/")
> @WebMethod
> public Object getObject(
> @QueryParam("id")
> @WebParam(name="id")
> long id) {
> //this got invoked
> return new MyObject();
> }
>
> URL: http://localhost:8080/cxf/rest/Objects/search?id=1
>
> The case above only happens with IE giving all those extra headers.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> Ok. If you could have both methods in ObjectService annotated with Path value which is a bit more specific than '/' then it will
>> also fix the problem, ex, URI ending with "/search" will get getObject() selected while those starting with "/search/*" will
>> result in a locator being invoked...
>>
>> Cheers, Sergey
>>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Let me clarify that
Given:
@GET
@Path("/search/")
@WebMethod
public MyObjects getObjects(){
//this is the method that I was invoking... supposedly
//using a list wrapper as advised in the user's guide
return new MyObjects(new MyObject());
}
@GET
@Path("/")
@WebMethod
public Object getObject(
@QueryParam("id")
@WebParam(name="id")
long id) {
//this got invoked
return new MyObject();
}
URL: http://localhost:8080/cxf/rest/Objects/search?id=1
The case above only happens with IE giving all those extra headers.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> Ok. If you could have both methods in ObjectService annotated with
> Path value which is a bit more specific than '/' then it will also fix
> the problem, ex, URI ending with "/search" will get getObject()
> selected while those starting with "/search/*" will result in a
> locator being invoked...
>
> Cheers, Sergey
>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
Ok. If you could have both methods in ObjectService annotated with Path value which is a bit more specific than '/' then it will
also fix the problem, ex, URI ending with "/search" will get getObject() selected while those starting with "/search/*" will result
in a locator being invoked...
Cheers, Sergey
> Hi Sergey,
>
> I'll wait for the fix. I cannot move the path annotation from the object to the service since it is possible that the object
> involve has a whole set of other fields. I also tried the following:
>
> //an extra method
> @GET
> @Path("/search/")
> @WebMethod
> public MyObjects getObjects(){
> //using a list wrapper as advised in the user's guide
> return new MyObjects(new MyObject());
> }
>
> if I invoke http://localhost:8080/cxf/Objects/search/ , "getObject" gets invoked.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> What is happening is that with
>>
>>> Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*]
>>
>> the wildcard is the less specific accept type which is checked last, when selecting between multiple matching methods.
>> I think what is happening is that when the first specific accept value is tried, the getObject() method is discarded is it
>> inherits text/xml but the subresource method is matched due to the fact the actual method selection is done at a later stage.
>>
>> Actually, I think there's a flaw in this algorithm (in CXF JAXRS that is), in that all accept types should be tried for all the
>> methods, even if the forst accept type has produced a candidate, in which case */* will ensure that the getObject() is selected
>> too and it will be picked up first on the basis that it's a resource method.
>>
>> I'll get it fixed for 2.2, but in meantine please move /field1 from MyObject.getField1() to ObjectService.getObjectProperty() and
>> it should fix the problem...
>>
>> Thanks, Sergey
>>
>>> Hi All,
>>>
>>> I was testing the web service I have created and it works without a hitch when using HttpClient as ... well client. However, if
>>> I use I.E. to check (haven't tested fire fox or any browser yet), I encounter the following error:
>>>
>>> javax.ws.rs.WebApplicationException
>>> at org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:295)
>>> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:161)
>>> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:67)
>>> at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
>>> at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>>> at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
>>> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226)
>>> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89)
>>> at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
>>> at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:305)
>>> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:138)
>>> at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:163)
>>> at org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:145)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>>> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>>> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>>> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
>>> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
>>> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>>> at java.lang.Thread.run(Thread.java:619)
>>>
>>> Then I receive a runtime exception client side. What I find weird is that a method was properly invoked. More specifically, the
>>> subresource locator was used. There are two methods defined and annotated as follows:
>>>
>>> @Consumes("*/*")
>>> @Produces("text/xml")
>>> @Path("/Objects")
>>> public class ObjectService{
>>> @GET
>>> @Path("/")
>>> @WebMethod
>>> public Object getObject(
>>> @QueryParam("id")
>>> @WebParam(name="id")
>>> long id) {
>>> //this is the method that I was invoking... supposedly
>>> logger.info("get Object received: " + id);//Note this
>>> return new MyObject();
>>> }
>>>
>>> @Path("/")
>>> @WebMethod(exclude=true)
>>> public Object getObjectProperty(
>>> @QueryParam("id")
>>> @WebParam(name="id")
>>> long id) {
>>> //this got invoked ... but should not have been
>>> logger.info("get Object Property received: " + id);//Note this
>>> return getObject(id);
>>> }
>>> }
>>>
>>> @XmlType(name="MyObject")
>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>> @XmlRootElement(name="MyObject")
>>> public class MyObject {
>>> @GET
>>> @Path("/field1")
>>> public String getField1() {
>>> return "field1";
>>> }
>>> public void setField1() {
>>> }
>>> }
>>>
>>> The debug log shows the following:
>>>
>>> 2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object Property received: 1
>>> 2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object received: 1
>>>
>>> I am assuming it is having a problem finding the subresource since technically, it shouldn't even be the method being invoked.
>>> URL being used is:
>>>
>>> http://localhost:8080/cxf/Objects/?id=1
>>>
>>> I am not sure if it helps but maybe the extra headers affects this? These are not received when HttpClient is used.
>>>
>>> accept-language=[en-us], user-agent=[Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)], accept-encoding=[gzip, deflate],
>>> ua-cpu=[x86], Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*]
>>>
>>> I am using the following:
>>> tomcat 6.0.13
>>> java 1.6
>>> cxf 2.2-snapshot (Jan 27)
>>>
>>> Thanks in advance.
>>>
>>> Gabo
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.10.25/1957 - Release Date: 02/17/09 07:07:00
>>
>>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
I'll wait for the fix. I cannot move the path annotation from the object
to the service since it is possible that the object involve has a whole
set of other fields. I also tried the following:
//an extra method
@GET
@Path("/search/")
@WebMethod
public MyObjects getObjects(){
//using a list wrapper as advised in the user's guide
return new MyObjects(new MyObject());
}
if I invoke http://localhost:8080/cxf/Objects/search/ , "getObject" gets
invoked.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> What is happening is that with
>
>> Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> application/x-shockwave-flash, */*]
>
> the wildcard is the less specific accept type which is checked last,
> when selecting between multiple matching methods.
> I think what is happening is that when the first specific accept value
> is tried, the getObject() method is discarded is it inherits text/xml
> but the subresource method is matched due to the fact the actual
> method selection is done at a later stage.
>
> Actually, I think there's a flaw in this algorithm (in CXF JAXRS that
> is), in that all accept types should be tried for all the methods,
> even if the forst accept type has produced a candidate, in which case
> */* will ensure that the getObject() is selected too and it will be
> picked up first on the basis that it's a resource method.
>
> I'll get it fixed for 2.2, but in meantine please move /field1 from
> MyObject.getField1() to ObjectService.getObjectProperty() and it
> should fix the problem...
>
> Thanks, Sergey
>
>> Hi All,
>>
>> I was testing the web service I have created and it works without a
>> hitch when using HttpClient as ... well client. However, if I use
>> I.E. to check (haven't tested fire fox or any browser yet), I
>> encounter the following error:
>>
>> javax.ws.rs.WebApplicationException
>> at
>> org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:295)
>>
>> at
>> org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:161)
>> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:67)
>> at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
>>
>> at
>> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
>>
>> at
>> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
>>
>> at
>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226)
>>
>> at
>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89)
>>
>> at
>> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
>>
>> at
>> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:305)
>>
>> at
>> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:138)
>>
>> at
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:163)
>>
>> at
>> org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:145)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
>>
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>>
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>>
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>>
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>>
>> at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
>>
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> Then I receive a runtime exception client side. What I find weird is
>> that a method was properly invoked. More specifically, the
>> subresource locator was used. There are two methods defined and
>> annotated as follows:
>>
>> @Consumes("*/*")
>> @Produces("text/xml")
>> @Path("/Objects")
>> public class ObjectService{
>> @GET
>> @Path("/")
>> @WebMethod
>> public Object getObject(
>> @QueryParam("id")
>> @WebParam(name="id")
>> long id) {
>> //this is the method that I was invoking... supposedly
>> logger.info("get Object received: " + id);//Note this
>> return new MyObject();
>> }
>>
>> @Path("/")
>> @WebMethod(exclude=true)
>> public Object getObjectProperty(
>> @QueryParam("id")
>> @WebParam(name="id")
>> long id) {
>> //this got invoked ... but should not have been
>> logger.info("get Object Property received: " + id);//Note this
>> return getObject(id);
>> }
>> }
>>
>> @XmlType(name="MyObject")
>> @XmlAccessorType(XmlAccessType.PROPERTY)
>> @XmlRootElement(name="MyObject")
>> public class MyObject {
>> @GET
>> @Path("/field1")
>> public String getField1() {
>> return "field1";
>> }
>> public void setField1() {
>> }
>> }
>>
>> The debug log shows the following:
>>
>> 2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object Property
>> received: 1
>> 2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object received: 1
>>
>> I am assuming it is having a problem finding the subresource since
>> technically, it shouldn't even be the method being invoked. URL being
>> used is:
>>
>> http://localhost:8080/cxf/Objects/?id=1
>>
>> I am not sure if it helps but maybe the extra headers affects this?
>> These are not received when HttpClient is used.
>>
>> accept-language=[en-us], user-agent=[Mozilla/4.0 (compatible; MSIE
>> 7.0; Windows NT 5.1)], accept-encoding=[gzip, deflate], ua-cpu=[x86],
>> Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> application/x-shockwave-flash, */*]
>>
>> I am using the following:
>> tomcat 6.0.13
>> java 1.6
>> cxf 2.2-snapshot (Jan 27)
>>
>> Thanks in advance.
>>
>> Gabo
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.237 / Virus Database: 270.10.25/1957 - Release Date: 02/17/09 07:07:00
>
>
Re: [JAXRS][IE] subresource locator feature getting confused
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
What is happening is that with
> Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*]
the wildcard is the less specific accept type which is checked last, when selecting between multiple matching methods.
I think what is happening is that when the first specific accept value is tried, the getObject() method is discarded is it inherits
text/xml but the subresource method is matched due to the fact the actual method selection is done at a later stage.
Actually, I think there's a flaw in this algorithm (in CXF JAXRS that is), in that all accept types should be tried for all the
methods, even if the forst accept type has produced a candidate, in which case */* will ensure that the getObject() is selected too
and it will be picked up first on the basis that it's a resource method.
I'll get it fixed for 2.2, but in meantine please move /field1 from MyObject.getField1() to ObjectService.getObjectProperty() and it
should fix the problem...
Thanks, Sergey
> Hi All,
>
> I was testing the web service I have created and it works without a hitch when using HttpClient as ... well client. However, if I
> use I.E. to check (haven't tested fire fox or any browser yet), I encounter the following error:
>
> javax.ws.rs.WebApplicationException
> at org.apache.cxf.jaxrs.utils.JAXRSUtils.findTargetMethod(JAXRSUtils.java:295)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:161)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:67)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:56)
> at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:92)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:226)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:89)
> at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
> at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:305)
> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:138)
> at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:163)
> at org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServlet.java:145)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:619)
>
> Then I receive a runtime exception client side. What I find weird is that a method was properly invoked. More specifically, the
> subresource locator was used. There are two methods defined and annotated as follows:
>
> @Consumes("*/*")
> @Produces("text/xml")
> @Path("/Objects")
> public class ObjectService{
> @GET
> @Path("/")
> @WebMethod
> public Object getObject(
> @QueryParam("id")
> @WebParam(name="id")
> long id) {
> //this is the method that I was invoking... supposedly
> logger.info("get Object received: " + id);//Note this
> return new MyObject();
> }
>
> @Path("/")
> @WebMethod(exclude=true)
> public Object getObjectProperty(
> @QueryParam("id")
> @WebParam(name="id")
> long id) {
> //this got invoked ... but should not have been
> logger.info("get Object Property received: " + id);//Note this
> return getObject(id);
> }
> }
>
> @XmlType(name="MyObject")
> @XmlAccessorType(XmlAccessType.PROPERTY)
> @XmlRootElement(name="MyObject")
> public class MyObject {
> @GET
> @Path("/field1")
> public String getField1() {
> return "field1";
> }
> public void setField1() {
> }
> }
>
> The debug log shows the following:
>
> 2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object Property received: 1
> 2009-02-18 07:38:17,640 | [INFO ][80-1] | get Object received: 1
>
> I am assuming it is having a problem finding the subresource since technically, it shouldn't even be the method being invoked. URL
> being used is:
>
> http://localhost:8080/cxf/Objects/?id=1
>
> I am not sure if it helps but maybe the extra headers affects this? These are not received when HttpClient is used.
>
> accept-language=[en-us], user-agent=[Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)], accept-encoding=[gzip, deflate],
> ua-cpu=[x86], Accept=[image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*]
>
> I am using the following:
> tomcat 6.0.13
> java 1.6
> cxf 2.2-snapshot (Jan 27)
>
> Thanks in advance.
>
> Gabo