Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of kraythe@gmail.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADKGCnfvhU1-RKDv1Lit1p_6f+NAwAhU2U5=z_=yw4UXnu=KeA@mail.gmail.com>
References: 
 <3CCCD9AF5E124D4496F5F50E7CD2168911E52AA9@DEWDFEMB19C.global.corp.sap>
	<CALhQg-aDm1FxZm2bipf2_0EK2o8hfL68RLKO_zjZuUQ560LmdA@mail.gmail.com>
	<005b01cef5ce$10000d30$30002790$@de>
	<3CCCD9AF5E124D4496F5F50E7CD2168911E53876@DEWDFEMB19C.global.corp.sap>
	<CADKGCnfvhU1-RKDv1Lit1p_6f+NAwAhU2U5=z_=yw4UXnu=KeA@mail.gmail.com>
Date: Mon, 16 Dec 2013 16:01:18 -0600
Message-ID: 
 <CAGfr3_mZgJNQh1e52jZd8Np-o8ANq-oQVcz314-e9k=HG7nfBA@mail.gmail.com>
Subject: Re: Why Pass Java object in Twitter (& other) component
From: "kraythe ." <kraythe@gmail.com>
To: Camel Users List <users@camel.apache.org>
Content-Type: multipart/alternative; boundary=20cf307d045a94cc1904edadf3e3

--20cf307d045a94cc1904edadf3e3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 <bruno.borges@gmail.com>wrote=
:

> Hi,
>
> The reason to keep twitter4j.Status as the payload is to avoid conversion=
s
> 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 sa=
y
> 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 <arpit.goyal@sap.com> wrote=
:
>
> > Hi Jan,
> >
> > Thanks for the explanation. So if I am writing camel component, I can u=
se
> > 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 da=
ta
> > 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 ne=
w
> > camel component.
> >
> > >>> For further conversion you could use the typeconverters.
> >
> > The typeconvertors of Twitter returns only partial information of Statu=
s
> > object. Doesn't pass on the Geo location for example.
> >
> > Regards,
> > Arpit.
> >
> > -----Original Message-----
> > From: Jan Mat=E8rne (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...). Th=
e
> > components job is to transform that data to "exchange".
> >
> > For further conversion you could use the typeconverters.
> >
> > (I hope to be right ;)
> >
> >
> > Jan
> >
> >
>

--20cf307d045a94cc1904edadf3e3--