Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
From: <christian.jacob@innogy.com>
To: <users@camel.apache.org>
Subject: AW: Camel Jackson unmarshal behavior and object type
Thread-Topic: Camel Jackson unmarshal behavior and object type
Thread-Index: AdNtVQ67xJyTSAI/RHevIsl73oVGGQAQbfng
Date: Tue, 5 Dec 2017 07:01:44 +0000
Message-ID: <DB6PR0701MB26154BBCA52BE816A16490FD973D0@DB6PR0701MB2615.eurprd07.prod.outlook.com>
References: <99fd3041744349ce86609200fecf91c9@ES12AMSNLNT.srn.sandia.gov>
In-Reply-To: <99fd3041744349ce86609200fecf91c9@ES12AMSNLNT.srn.sandia.gov>
Accept-Language: de-DE, en-US
Content-Language: de-DE
received-spf: None (protection.outlook.com: innogy.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 53724fc4-1418-4b0b-dd9a-08d53bae0b5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2017 07:01:44.2930
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f481d56f-c63d-4d74-8406-d64e74f44395
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2616
archived-at: Tue, 05 Dec 2017 07:02:03 -0000

Hi Allen,

That seems to me to be a matter of streaming, look here: http://camel.apach=
e.org/stream.html

Regards,
Christian

-----Urspr=FCngliche Nachricht-----
Von: Bagwell, Allen F [mailto:afbagwe@sandia.gov]
Gesendet: Dienstag, 5. Dezember 2017 00:12
An: users@camel.apache.org
Betreff: Camel Jackson unmarshal behavior and object type

I am using camel-jackson to marshal/unmarshal in a blueprint route for use =
with a CXF rest client. The rest call expects a JSON string and returns one=
 in its response.

I can do an unmarshal like in the examples provided on the Camel Jackson pa=
ge and it works fine, but I'm having trouble with the marshal element.

<dataFormats>
  <json id=3D"jsonSend" library=3D"Jackson" unmarshalTypeName=3D"my.app.jso=
n.SendMessage" />
  <json id=3D"jsonReceive" library=3D"Jackson" unmarshalTypeName=3D"my.app.=
json.ReturnMessage" /> </dataFormats>

...
<route>
...
  <marshal ref=3D"jsonSend"/>
  <log message=3D"${body}" loggingLevel=3D"INFO"/> <!- prints the JSON stri=
ng -->
  <to uri=3D"cxfrs://bean:rsClient" id=3D"clientEndpoint"/>
  <unmarshal ref=3D"jsonReceive"/>
  <log message=3D"${body}" loggingLevel=3D"INFO"/> <!- prints a reference t=
o a ReturnMessage object --> ...
</route>

When I attempt to marshal, I have a SendMessage object as my (in) message b=
ody. After the marshalling occurs, the logging message prints out  ${body} =
as an equivalent JSON string.

At this point, however, the route hangs and the rest call is never reached.

It turns out to fix this, I have to put

<convertBodyTo type=3D"java.lang.String"/>

after the marshal element.

Is this expected behavior? I didn't see a need for this in the examples.

It occurred to me that the logging element could be calling a toString meth=
od under the hood, so what I'm seeing in the log is not really the object t=
hat is present. However it seems odd to me that after a call to marshal tha=
t the ${body} is not a String since the whole point is to serialize the POJ=
O.

The unmarshal step definitely converts the return JSON string to a POJO, an=
d the log statement following it indicates that ${body} is a ReturnMessage =
object.
----------------------------------------------------------------
innogy SE Vorsitzender des Aufsichtsrates: Dr. Werner Brandt
Vorstand: Peter Terium (Vorsitzender), Dr. Hans Buenting,
Dr. Bernhard Guenther, Martin Herrmann, Hildegard Mueller, Uwe Tigges
Sitz der Gesellschaft: Essen, Eingetragen beim Amtsgericht Essen,
Handelsregister-Nr. HRB 27091, USt-IdNr. DE304171711