Hi Sergey,
Thanks for the info on how to set up the debug. The result:
In JAXRSUtils.findTargetMethod, the candidate that gets selected is the
subresource locator: getMyObjectProperty(). This method in turn invokes
the method getMyObject(). As to why, do I have to specify the Consumes
and Produces in the subresource as well?
Gabo
Gabo Manuel wrote:
Hi Sergey,
Almost:
"but in the method it suddenly becomes GET"
the method remains as PUT/POST at the method level.
I checked the logs, there is no presence of either _method or Override
in the URI and header respectively.
I'll try to follow the steps to setup eclipse.
Gabo.
Sergey Beryozkin wrote:
Hi Gabo
according to this table, what happens is that when you specify a
Content-Type (application/xml) which does not match the one used by
the resource class (text/xml), you see a @GET annotated getMyObject()
invoked for borth PUT and POST invocations on tomcat/iplanet but not
on jetty. Moreover, in the interceptor you can see that it is still
PUT/POST but in the method it suddenly becomes GET...If you specify a
correct content type (text/xml) then all works as expected.
This is quite unusual to say the least :-). JAXRSInInterceptor can
reset the HTTP method, but only if the following conditions are true :
- X-HTTP-Method-Override header has been set, ex, you have issued
POST but X-HTTP-Method-Override=GET has been added either at the
client side or by the server-side admin filter
- _method=GET query has been added to the request URI
RequestPreprocessor is the only place where it might happen. Can you
verify please neither X-HTTP-Method-Override header nor _method query
are available ?
The other confusing bit is that this method substitution occurs only
if we have an application/xml vs text/xml case. This does not quite
make sense. I'll try to rerun the test on Tomcat (like yourself, I
confirmed it was working ok on Jetty). I feel though that if you
could just download the CXF source and debug it then it would be the
fastest way forward. It is very likely there's some
production-specific condition that is afffecting it all which I won't
be able to reproduce locally
thanks, Sergey
----- Original Message ----- From: Gabo Manuel To:
users@cxf.apache.org Sent: Thursday, January 28, 2010 6:47 AM
Subject: Re: [Fwd: Re: [CXF-2.2.5][Spring2.5.5][jre1.5] No mapped
method]
Hi Sergey,
Some corrections:
payload type http method jetty tomcat iplanet
submitted interceptor method invoked http method on invoke method
invoked http method on invoke method invoked http method on invoke
application/xml PUT PUT error: no method mapped n/a
getMyObject GET 401 n/a text/xml PUT PUT insertMyObject PUT
insertMyObject PUT 401 n/a application/xml POST POST error:
no method mapped n/a getMyObject GET 401 n/a text/xml POST
POST updateMyObject POST updateMyObject POST updateMyObject POST
Gabo
Gabo Manuel wrote:
----------------------------------------------------------------------------
Subject: Re: [CXF-2.2.5][Spring2.5.5][jre1.5] No mapped
method From: Gabo Manuel <kman...@solegysystems.com>
Date: Thu, 28 Jan 2010 06:44:21 +0000 To:
users@cxf.apache.org To: users@cxf.apache.org
Hi Sergey,
I added the following details:
1. I have the interceptor that processes the authentication
details display the http method.
2. I have the methods display the http method
The code I used to retrieve the method is as follows:
PhaseInterceptorChain.getCurrentMessage().getExchange().getInMessage().get(Message.HTTP_REQUEST_METHOD)
The result:
payload type http method jetty tomcat iplanet
submitted interceptor method invoked http method on invoke method
invoked http method on invoke method invoked http method on invoke
application/xml PUT PUT error: no method mapped n/a
getMyObject GET 401 n/a text/xml PUT PUT insertMyObject PUT
insertMyObject PUT 401 n/a application/xml POST POST error:
no method mapped n/a POST GET 401 n/a text/xml POST POST
updateMyObject POST updateMyObject POST updateMyObject POST
where Jetty is as the supplied server class in the previously
posted archive.
Gabo
Sergey Beryozkin wrote: I did a quick test by creating a
servlet based endpoint (using MyService, MyServiceImpl, MyObject and
SearchFilter from the test.zip) and POSTing a MyObject instance to it
and I got a POST-annotated MyServiceImpl.updateMyObject invoked...
Not sure how you see a @GET-annotated method invoked. The code
responsible for the selection compares the HTTP methods (the actual
request verb and the one which is accociated with a given method
through @GET, etc).
Please do some debugging and let me know what you've found, ex,
add a breakpoint in JAXRSInInterceptor and see how an operation is
being selected.
cheers, Sergey
Hi Gabo
Hi Sergey,
Sorry for the troubles. It's a red herring, something to do
with the securities set by our Sys Admin. I see the the transactions
recorded as:
222.127.215.98 - - [25/Jan/2010:04:40:53 +0000] "POST
/MyService/?comment=test HTTP/1.1" 401 0 222.127.215.98 - -
[25/Jan/2010:04:40:53 +0000] "POST /MyService/?comment=test HTTP/1.1"
400 116
But the transaction still goes into my app. It is just odd
that even if the interceptor retrieves the HttpMethod as POST, the
method selection somehow gets a GET:
So do you still get a @GET annotated method invoked even when
HttpMethod=POST ? Does not look like a red herring to me :-).
2010-01-25 04:40:53,397 [INFO ][ee-2][
RestInHandler] - exchange at end:
{password=89f2b9fbd6c6b2c0e5ab90ce18adc0e9,
org.apache.cxf.binding.binding=org.apache.cxf.binding.xml.xmlbind...@192322e,
HttpMethod=POST, transactiosnType=ReST,
org.apache.cxf.bus=org.apache.cxf.bus.cxfbusi...@11ca33b, ...
Again, my apologies for this.
No problems :-), I'm still confused a bit. Is the resource
class code you posted in the first message of this thread close
enough to the actual code that you use ? I'd like to do a test and
see what is being invoked...
thanks, Sergey
Gabo
Sergey Beryozkin wrote:
Hi
Hi All,
Found the cause for most. Still an odd error though. So
here is the cause:
The service explicitely says @Consumes("text/xml") ,
while my client specified:
RequestEntity re = new FileRequestEntity(
new File("somefile.txt"),
"application/xml; charset=ISO-8859-1");
After changing this to text/xml. POST and DELETE
succeeded.
OK...
Remaining issue:
1. Why was no exception thrown? 2. Why
did it revert to GET?
I'll need some help here. Can you verify it is GET ? Any
chance you can attach a simple test case to a JIRA ? I
honestly do not see POST being mapped to GET happening....Does
request get modified somehow by some interceptor ?
cheers, Sergey
3. PUT still requires that basic authentication,
although I would be checking with our SysAdmin. I think this would be
server specific.
Gabo
