camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Borges <>
Subject Re: Why Pass Java object in Twitter (& other) component
Date Mon, 16 Dec 2013 19:14:26 GMT

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:

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
* <>*

On Wed, Dec 11, 2013 at 1:59 AM, Goyal, Arpit <> 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) []
> Sent: Tuesday, December 10, 2013 11:04 PM
> To:
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message