jQuery in Action, 2nd edition*
The moose likes Tomcat and the fly likes Soap truncated message (501 error not method implemented) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Soap truncated message (501 error not method implemented)" Watch "Soap truncated message (501 error not method implemented)" New topic

Soap truncated message (501 error not method implemented)

Oscar G. Rodriguez

Joined: Nov 05, 2011
Posts: 15

I'm using tomcat 7.0.42 to process several jax-ws webservice.

Sometimes requests are not processed, and the only info about it in tomcat that I've found, is the localhost_access_log file. - - [26/Apr/2014:22:11:59 +0200] "POST /app/Service HTTP/1.1" 200 778 - - [26/Apr/2014:22:12:00 +0200] "POST /app/Service HTTP/1.1" 200 778 - - [26/Apr/2014:22:12:00 +0200] "nvelope>POST /app/Service HTTP/1.1" 501 1155

In client log (cxf client) this is the error

PhaseInterceptorChain [ActiveMQ Session Task-956] |: Interceptor for {http://www.vorwerk.com/SASO/TransactionStatusNotify}ITransactionStatusNotifyServiceService#{http://www.vorwerk.com/SASO/TransactionStatusNotify}notifyTransactionStatus has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Response was of unexpected text/html ContentType. Incoming portion of HTML stream: <html><head><title>Apache Tomcat/7.0.42 - Informe de Error</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>Estado HTTP 501 - El Metodo e>POST no esta implementado por este servlet para esta URI</h1><HR size="1" noshade="noshade"><p><b>type</b> Informe de estado</p><p><b>mensaje</b> <u>El Metodo e>POST no esta implementado por este servlet para esta URI</u></p><p><b>descripciĆ³n</b> <u>El servidor no soporta la funcionalidad necesaria para rellenar este requerimiento.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.42</h3></body></html>
at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:79)

The tomcat message says that

Status HTTP 501 - Method e>POST is not implemented by this servlet for this URI

type Status report

messagge Method e>POST is not implemented by this servlet for this URI

description Server doesn't support the functionality to fullfill the requirement

Sorry about the transalation, but I didn't find the english message.

It happens in two different services, and if I take the request from the client log and send it with SoapUI it works ok. It's like the request is truncated.

Tomcat is responding a HTML error about wrong service, but the request and service are OK. I don't know if it is coincidence, but for a month we started tomcat with the Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true property to catch more info about the error and we didn't have it, when we removed the property, we have this error again.

Any idea about what is happening or how we can look for more info?

Thanks and regards.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16160

Actually, this isn't Tomcat, it's Apache CXF at the root of everything. You just getting a Tomcat error webpage back and your SOAP client doesn't know how to handle an unexpected HTML webpage as a response to a SOAP request. SOAP, after all, has its own protocol-specific way of receiving errors within a SOAP envelope, not as HTML.

The 501 message indicates that no CXF business component has a method paired with the URL "app/Service" (or maybe "/Service" in webapp "app"???) that's enabled for POST-format requests.

CXF can handle both SOAP and ReST-form requests. From what I can see, your client sent out SOAP, but the CXF in your server webapp thought it was a ReST request, so there's probably some configuration adjustment required.

I have only done ReST in CXF and haven't read the docs lately, so what little I knew of its configuration for SOAP, I've forgotten, alas.

Customer surveys are for companies who didn't pay proper attention to begin with.
Oscar G. Rodriguez

Joined: Nov 05, 2011
Posts: 15
Hi Tim,

the server doesn't use cxf, only the client.

The service works ok, every day o we process thousands f request but sometimes appears a few of them that have this error. I have no problem with the error in the client side, I only want to avoid the error in the server side.

As I said, I know the request is correct because client is logging it, and if I send it to the service by SoapUI it works. It's not a data problem, and I think that neither request size because I have bigger request that work.

It's like the request arrives to the server and it can't identify it as a soap request, but I can't see the whole request in the server, only the final tag in the localhost_access_log file. I don't know how I can log it in the server or why it is happening. I don't know if it's only a coincidence, but with the dump property I haven't this problem, maybe the dump introduce a needed delay or avoid a problem with a buffer.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16160

I love the way I can miss major sentences in a person's problem description.

All I can say then is that Tomcat has no ability itself to handle SOAP nor ReST. Tomcat implements only the Servlet and JSP components of the J2EE stack aside from a few support facilities such as its JNDI and connection pool resources. So there is something in the server app that has to parse and interpret incoming SOAP requests and to format SOAP responses, whether that something is CSF, Apache Axis, some other support facility or even brute force roll-their own code.

And that something, whatever it is, isn't resolving the request, nor is it attempting to format its resolution error in SOAP format, but instead bouncing the failure up to Tomcat's default error page for reporting.

OK. Looking even more closely at your error, that "something" is jax-ws.

It does, however, seem to think that your request is made for an unmapped URI. Which would indicate that either something's mis-configured, there's a bug in the version of jax-ws that's in the server webapp, or even that there's a reliability problem with the network itself.

Just to repeat, Tomcat doesn't have anything to do with this. It's serving solely as the HTTP transport and routing part of the server system, and its history of reliability is too long to make it a primary suspect (although it it makes you feel better, you can always try a different Tomcat version). What I would do is introduce a SOAP interceptor tool into the mix so that you could see precisely what the failing request looks like and what the response looks like going over the network without any garbling by the client and server code. If things "look" OK, then check to see if there are whitespaces going into the text that might be causing the software to mis-interpret things.
It is sorta covered in the JavaRanch Style Guide.
subject: Soap truncated message (501 error not method implemented)