HI Gabo

You may recall that this is exactly what I suggested was happening in the very 
first reply in this thread.

Basically, you have various resource methods (which are not subresource locators) annotated with text/xml. You have a POST application/xml request coming in and thus neither if those methods can get selected but a subresource locator is selected, given that it matches the path and it will be an object returned by this locator that will be checked next for a matching method if any. Given that this subresource locator invokes getMyObject internally, you see getMyObject invoked. Subresource locators can invoke internally whatever methods they need to, what matters is that it is what this locator returns that will be checked next for the final method be invoked.

cheers, Sergey

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












Reply via email to