NoSuchMethodError in Tomcat embedded MULE when exe

When running Mule ESB 3.2.1 as embedded server inside Tomcat 7.0.27 (executed with webapp-runner), during execution of a flow with the Http endpoint, while sending response back to caller, an Exception is raised:

java.lang.NoSuchMethodError: org.apache.tomcat.util.http.ServerCookie.appendCookieValue(Ljava/lang/StringBuffer;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZ)V

Exception Below:

org.mule.api.MuleRuntimeException: Connector that caused exception is: connector.http.mule.default

    at org.mule.transport.AbstractConnector.handleWorkException(AbstractConnector.java:2034)

    at org.mule.transport.AbstractConnector.workCompleted(AbstractConnector.java:1998)

    at org.mule.work.WorkerContext.run(WorkerContext.java:369)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

    at java.lang.Thread.run(Thread.java:662)

Caused by: java.lang.NoSuchMethodError: org.apache.tomcat.util.http.ServerCookie.appendCookieValue(Ljava/lang/StringBuffer;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZ)V

    at org.mule.transport.http.CookieHelper.formatCookieForASetCookieHeader(CookieHelper.java:310)

    at org.mule.transport.http.transformers.MuleMessageToHttpResponse.createResponse(MuleMessageToHttpResponse.java:261)

    at org.mule.transport.http.transformers.MuleMessageToHttpResponse.transformMessage(MuleMessageToHttpResponse.java:90)

    at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:145)

    at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:93)

    at org.mule.DefaultMuleMessage.applyAllTransformers(DefaultMuleMessage.java:1387)

    at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1348)

    at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1331)

    at org.mule.transport.AbstractMessageReceiver.applyResponseTransformers(AbstractMessageReceiver.java:235)

    at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:214)

    at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:163)

    at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:150)

    at org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest(HttpMessageReceiver.java:299)

    at org.mule.transport.http.HttpMessageReceiver$HttpWorker.processRequest(HttpMessageReceiver.java:258)

    at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:163)

    at org.mule.work.WorkerContext.run(WorkerContext.java:310)

回答1:

If you are using Mule 3.2.1, you can not use the http:response-builder. The feature is just not there. That's why you can't use it.

Check it out:

It's not in the doc: http://www.mulesoft.org/documentation-3.2/display/32X/HTTP+Transport+Reference
It's not in the source: https://github.com/mulesoft/mule/blob/mule-3.2.1/transports/http/src/main/java/org/mule/transport/http/config/HttpNamespaceHandler.java#L56

回答2:

I had this problem too. Check answer here.

Mule ESB does not work with cookie

In short, make sure you have provided group: 'org.apache.tomcat', name: 'coyote', version: '6.0.44' for mule 3.7.0.

In your case, you should have another library - tomcat-util 5.5.23 because you use different version of mule 3.2.1.

compile group: 'tomcat', name: 'tomcat-util', version: '5.5.23'

When you use SpringBoot, it ovverides a version of some library (depending on version of Spring and Mule), so you will get this error. You have class ServerCookie but the method appendCookieValue will disappear!

Solution - play with libraries. Or another bad workaround, write your own version of one of these classes that fail, and make sure classloader will use your version of the classes. (Again, creating a class with the same name and package to fix a bug - is a risky and bad thing...)