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 









Reply via email to