You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "Goyal, Arpit" <ar...@sap.com> on 2013/12/10 09:49:55 UTC
Why Pass Java object in Twitter (& other) component
Hi Colleagues,
I would like to understand the logic behind camel component allowing to migrate Java Objects. From Twitter component, after polling we get twitter4j.Status object. For any processing in the subsequent step we either use the TypeConvertor provided - which changes into String (and that to having only partial information of Status object) or we add custom processor to change it to XML/JSON.
Why not have standard behavior across camel components? Wanted to understand the logic behind it!!! Is it only to keep it flexible and give end-users ideal control with the data?
Regards,
Arpit.
RE: Why Pass Java object in Twitter (& other) component
Posted by "Goyal, Arpit" <ar...@sap.com>.
Hi Henryk,
Yeah, as Twitter Rest API returns JSON, may be that is much better to return JSON. Otherwise for integration the first step to get completed information from twitter4j.Status object is to write custom processor having dependency to twitter4j.Status (twitter4j Lib) and convert into the desired format (XML / JSON / CSV).
That is the reason why I wanted to understand why isn't done for Twitter camel component.
Regards,
Arpit.
-----Original Message-----
From: Henryk Konsek [mailto:hekonsek@gmail.com]
Sent: Tuesday, December 10, 2013 7:55 PM
To: users@camel.apache.org
Subject: Re: Why Pass Java object in Twitter (& other) component
Hi Arpit,
> 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?
Cheers.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: Why Pass Java object in Twitter (& other) component
Posted by "kraythe ." <kr...@gmail.com>.
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 <br...@gmail.com>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 <ar...@sap.com> 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:apache@materne.de]
> > Sent: Tuesday, December 10, 2013 11:04 PM
> > To: users@camel.apache.org
> > 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
> >
> >
>
Re: Why Pass Java object in Twitter (& other) component
Posted by Bruno Borges <br...@gmail.com>.
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 <ar...@sap.com> 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:apache@materne.de]
> Sent: Tuesday, December 10, 2013 11:04 PM
> To: users@camel.apache.org
> 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
>
>
RE: Why Pass Java object in Twitter (& other) component
Posted by "Goyal, Arpit" <ar...@sap.com>.
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:apache@materne.de]
Sent: Tuesday, December 10, 2013 11:04 PM
To: users@camel.apache.org
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
AW: Why Pass Java object in Twitter (& other) component
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
> > 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
Re: Why Pass Java object in Twitter (& other) component
Posted by Henryk Konsek <he...@gmail.com>.
Hi Arpit,
> 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?
Cheers.
--
Henryk Konsek
http://henryk-konsek.blogspot.com