We Keep Coding

Apache Camel difference between Exchange.ERRORHANDLER_HANDLED and Exchange.FAILURE_HANDLED property

I am using Apache Camel Framework and going through the documentation regarding the error handling , i am confused between Exchange.ERRORHANDLER_HANDLED and Exchange.FAILURE_HANDLED properties
Exchange.ERRORHANDLER_HANDLED: As per my understanding this property is to propagate the exception back to caller.
but not able to find any information Exchange.FAILURE_HANDLED on this.

Those are internal flags and should not be in-use by end users.

Spring Data Rest 2.4 Intermittent Error (ClassCastException)

Working with Spring Data Rest continues. Moving to 2.4.0 gave me more of the behavior I want, however now I am getting a strange intermittent exception.
About. . . 2/3 of the time when I reload or deploy my application, every SDR endpoint with data throws a 500, and gives the following:
GET /api/departments
--------------------
HTTP Status 500 - Could not write content: org.springframework.data.rest.webmvc.json.PersistentEntityJackson2Module$ProjectionResourceContentSerializer
cannot be cast to com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanSerializer
(through reference chain:
org.springframework.hateoas.PagedResources["_embedded"]
->java.util.UnmodifiableMap["departments"]
->java.util.ArrayList[0]
->org.springframework.data.rest.webmvc.json.ProjectionResource["content"]);
nested exception is com.fasterxml.jackson.databind.JsonMappingException:
org.springframework.data.rest.webmvc.json.PersistentEntityJackson2Module$ProjectionResourceContentSerializer
cannot be cast to com.fasterxml.jackson.databind.ser.impl.UnwrappingBeanSerializer
(through reference chain:
org.springframework.hateoas.PagedResources["_embedded"]
->java.util.UnmodifiableMap["departments"]
->java.util.ArrayList[0]
->org.springframework.data.rest.webmvc.json.ProjectionResource["content"])
(Full error report available: http://pastebin.com/xzzXkFiR )
Like I said, this does not occur every time I reload/deploy the app, but if it is occuring it's completely stuck, and a reload is the only way to fix it. Very odd behavior, wondering if anyone has any insight.
Issue does not occur if I roll back to Spring Data Rest 2.3.2
Thanks for the help, and please let me know what other relevant information I can provide.
SDR: 2.4.1
SFW: 4.2.1
SDJPA: 1.9.0
Some further testing
Issue also occurs with latest (2.5.0 SNAPSHOT).

I can observe the same issue after updating to Spring Data Rest 2.4.0. The issue is not deterministically reproducible. I do not have any statistics so far, but it occurs less frequently after updating Jackson dependencies from 2.4.0 to 2.6.0. Sometimes it still pops up, but then a reload is sufficient in my case. A minimal example would help to dive deeper into it.

Bugs in jackson-databind library. Upgrade to release train Gosling-SR3 once released.
See https://jira.spring.io/browse/DATAREST-716 and https://jira.spring.io/browse/DATAREST-743

SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a SOAP message

I want to run a java application which calls a web service. Everything works fine from the netbeans ide, but fails when I run the .jar generated. What could be the problem?
How can I check the content type that the error is pointing at?
the error says: "SEVERE: SAAJ0537: Invalid Content-Type. Could be an error message instead of a SOAP message. com.sun.xml.messaging.saaj.MessageImpl identifyContentType"
EDIT
I am realizing that the problem could be originated by the fact that the web service that Im consuming uses a custom data type, but I have no idea where to look.
Please help

Your question lacks the details that would help identify your problem (like, what web container are you using, some source code, etc) but I've encountered and resolved this same problem. I'm using Tomcat with Eclipse and apparently, the problem occurs because for some reason, Tomcat can't find some JARs even though I have specified them in my build path. The resolution is to put the JARs in the actual lib directory of Tomcat instead of in some project-specific location. (See this same case with log4j.)
What happens is this missing JAR causes the servlet to produce an internal server error when called. Tomcat generates an error page---which is of type "text/html"---and sends it back to client. So, client reads "text/html" instead of the expected "text/xml".
For a test this SOAP tutorial produces the specified error due to jaxm-api.jar but can be fixed with the solution I described above. I have verified this with Tomcat 7.
How can I check the content type that the error is pointing at?
A bit difficult to answer without some code. But if you are using javax.xml.soap.SOAPPart, it has methods to check the headers of the SOAP transaction. Check the javadocs. Shame it does not override toString(). But personally, I did not arrive at this answer with Java debug methods but via looking at TCP dumps.

Websphere JMS: Unable to deserialize object

I am using Websphere MQ 6.x and I am getting the following exception thrown when an object is read from the queue.
Caused by: javax.jms.MessageFormatException: MQJMS1061: Unable to deserialize object
at com.ibm.jms.JMSMessage.newMessageFormatException(JMSMessage.java:4982)
at com.ibm.jms.JMSObjectMessage.getObject(JMSObjectMessage.java:289)
I am able to see the serialized version of the message (class) using WMQ Tool. But when the application reads it this exception happens.
Any ideas why?

I think a early version 6.x had a problem with primitive types. Maybe its this:http://www-01.ibm.com/support/docview.wss?uid=swg1IC50448

have you tried trying to read and write the messages from the queue using other tools besides your application?
You can try and see if you can read and write the messages to your queues using RFH Util for example or MQ Explorer to see if the problem is with your application or with the MQ infrastructure.
What is the application that is reading the message from the MQ Queue?
HTH
Manglu

Is it possible that the application reading the message does not have the class in it's classpath ? Or a more subtle issue, it may not be visible to the thread's context classloader.
Do you have a longer stack trace that might supply more information ?

UnsupportedEncodingException thrown when using Resin and Grails

I've encountered a strange problem in a Grails webapp running under Grails:
java.io.UnsupportedEncodingException is thrown quite frequently due to various unknown encoding strings (such as "ISO8859_10", "ISO-8859-10"), and the strange thing is that this is done entirely within the Resin and Grails code. That is - no custom code is involved when the exception is thrown.
I'm not sure if it is Grails or the servlet container's code that should handle the exception. But I'd assume that the exception should be handled somewhere and not bubble up all the way to stderr.
This is the exception in full:
java.io.UnsupportedEncodingException: ISO-8859-10
at com.caucho.vfs.i18n.JDKWriter$OutputStreamEncodingWriter.<init>(JDKWriter.java:112)
at com.caucho.vfs.i18n.JDKWriter.create(JDKWriter.java:79)
at com.caucho.vfs.Encoding.getWriteEncoding(Encoding.java:231)
at com.caucho.server.connection.ToByteResponseStream.setEncoding(ToByteResponseStream.java:137)
at com.caucho.server.connection.AbstractHttpResponse.setLocale(AbstractHttpResponse.java:1683)
at com.caucho.server.connection.HttpServletResponseImpl.setLocale(HttpServletResponseImpl.java: 115)
at javax.servlet.ServletResponseWrapper.setLocale(ServletResponseWrapper.java:139)
at javax.servlet.ServletResponseWrapper.setLocale(ServletResponseWrapper.java:139)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1035)
at org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet.doDispatch(GrailsDispatcherServlet.java:290)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:114)
My questions:
Should the exception be handled? If so, is it the responsibility of the servlet container (Resin) or the web framework (Grails)?
How would you go about solving this? (I'd rather not having the exception log cluttered with exceptions that I can do nothing about.)

I don't know much about Grails, but maybe you could try to find out where this weird encoding comes from.
Do your requests send Accept-Charset headers?
Do things work better if you set the "file.encoding" system property to something meaningful like UTF-8 in your resin.conf?

You can also set up a localeResolver bean in your application context. The DispatcherServlet will use that to resolve the locale. I haven't tried it myself, but my suggestion is to use the org.springframework.web.servlet.i18n.FixedLocaleResolver. It will delegate to Locale.getDefault() if you don't have any set up.