The only real reason not to put an object of type X in an exchange is the need to convert in and out of the type. I dont think POJO mapping all json is a useful thing but there are many canonical data formats that can accomplish the same thing (such as a map). The only thing you have to keep in mind is when communicating with ActiveMQ you will have to make sure your object is in a standard format that JMS can handle. Although you can pass object messages, I strongly encourage the use of JSON for debuggability.
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 <http://www.linkedin.com/pub/robert-simmons/40/852/a39>* On Mon, Dec 16, 2013 at 1:14 PM, Bruno Borges <[email protected]>wrote: > Hi, > > The reason to keep twitter4j.Status as the payload is to avoid conversions > on every project. In my experience, to read JSON data inside a Java > application, developers tend to convert to a POJO-like object. So if this > would be the common case, why not use the twitter4j.Status object? I'd say > this is the right way. If one wants to convert to JSON, then a > TypeConverter is possible. > > For GeoLocation, please check this method: > http://twitter4j.org/javadoc/twitter4j/Status.html#getGeoLocation() > > If this method is not in the current version of the Twitter component, > please submit a JIRA ticket to upgrade Twitter4J version. > > PS: I'm one of the authors of the Twitter component > > Best regards > > *Bruno Borges* > (11) 99564-9058 > *www.brunoborges.com <http://www.brunoborges.com>* > > > On Wed, Dec 11, 2013 at 1:59 AM, Goyal, Arpit <[email protected]> wrote: > > > Hi Jan, > > > > Thanks for the explanation. So if I am writing camel component, I can use > > any library to return any object instead of standard XML / JSON / CSV > > format. Or if the external system returns in XML / JSON, pass on the data > > as it is in the 'Exchange' object. The question only comes because I > wanted > > to understand here the general trend before I go ahead and write the new > > camel component. > > > > >>> For further conversion you could use the typeconverters. > > > > The typeconvertors of Twitter returns only partial information of Status > > object. Doesn't pass on the Geo location for example. > > > > Regards, > > Arpit. > > > > -----Original Message----- > > From: Jan Matèrne (jhm) [mailto:[email protected]] > > Sent: Tuesday, December 10, 2013 11:04 PM > > To: [email protected] > > Subject: AW: Why Pass Java object in Twitter (& other) component > > > > > > Why not have standard behavior across camel components? > > > > > > Each component provides messages in the most > > > efficient/generic/convenient way it is possible in given context. > > > > > > What kind of standard message format are you thinking of? JSON for > > > example? > > > > A "common" format could only be some such generic as typeless XML or > JSON. > > Otherwise you would find use cases where some flag, some information, > some > > format is missed. > > The "common format" Camel uses for routing is "exchange" with its > > properties > > and in and out messages with headers. > > > > A Camel component has to deal with exactly one external system. So the > > format used there could be focused to that external system (http header, > > ssl > > credentials, ftp password, pgp encryption, jdbc datasource name...). The > > components job is to transform that data to "exchange". > > > > For further conversion you could use the typeconverters. > > > > (I hope to be right ;) > > > > > > Jan > > > > >
