Hi Vadim Yes file a JIRA otherwise we will forget it. I hope we get a new feature in Camel 1.5 to be able to set encoding options on the camel context / route so type convertions to/from bytes can use the encoding settings specified.
But fell free to add a JIRA, and if possible add a unit test that shows the bug. Isn't there any stacktrace or some evidence from camel-xstream that the marshal/unmarshal didn't work? The bug is solved much faster if you can provide a good start ;) Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: Vadim Chekan [mailto:[EMAIL PROTECTED] Sent: 22. juli 2008 08:12 To: [email protected] Subject: Re: xstream usage Ah-ha! Solved the mystery. Apparently you should define -Dfile.encoding=UTF-8 in your activemq.[bat|sh]. IMHO it is a bug, when xstream silently fails to produce output. If it does not like encoding settings, it should throw an exception. I already have discovered that this setting in Eclipse prevented me from seeing xml output but I decided that it is because body of xml document was a byte[] and I had no clue that xml writer will refuse to work with non-unicode settings. Should I file JIRA issue? Vadim. Claus Ibsen wrote: > Hi > > Ah yeah the primitive types in arrays is printed with rather stupid names for > its classname. You get the X[ stuff that looks as if something is wrong. > > Hmmm maybe we can improve Camel here to print a neater name for this ;) > > > Med venlig hilsen > > Claus Ibsen > ...................................... > Silverbullet > Skovsgårdsvænget 21 > 8362 Hørning > Tlf. +45 2962 7576 > Web: www.silverbullet.dk > -----Original Message----- > From: Vadim Chekan [mailto:[EMAIL PROTECTED] > Sent: 22. juli 2008 06:40 > To: [email protected] > Subject: Re: xstream usage > > Yesh, that's what I did. As Claus advised I also inserted my own > Processor to dump additional information. Apparently > marshall().xstream() returns array of size 0. > Too bad it works fine under Eclipse. I keep digging. Most likely it is > something with classpath/libraries. > > To my surprise (most of my experience is c#) byte[].class.getName() > returns "[B". At first I thought it is some binary garbage and only > getCanonicalName clarified the situation :))) > > Vadim. > > James Strachan wrote: >> Turning on the trace output can help see what the real payloads of the >> messages are at each step of a route... >> http://activemq.apache.org/camel/tracer.html >> >> 2008/7/20 Claus Ibsen <[EMAIL PROTECTED]>: >>> Hi >>> >>> You could add a process step where you can debug / log out your exchange. >>> And 100% determine the body type. >>> >>> It does look like a strange body type? The code does after all just print >>> its classname (albeit removing java.lang) for the standard types. >>> >>> Does it print the body content also? Looks like you cutted the logging >>> short in this mail. >>> >>> >>> Med venlig hilsen >>> >>> Claus Ibsen >>> ...................................... >>> Silverbullet >>> Skovsgårdsvænget 21 >>> 8362 Hørning >>> Tlf. +45 2962 7576 >>> Web: www.silverbullet.dk >>> >>> -----Original Message----- >>> From: Vadim Chekan [mailto:[EMAIL PROTECTED] >>> Sent: 19. juli 2008 23:35 >>> To: [email protected] >>> Subject: xstream usage >>> >>> I'm having problems with xstrem. I'm trying to convert jdbc output >>> into xml and then extract a node I'm interested in. >>> Host application: activemq-5.1.0 >>> Camel: today's trunk build. >>> Code: >>> from("activemq:vadim33"). >>> marshal(). >>> xstream(). >>> to("activemq:vadim44"); >>> >>> After marshaling I get some strange body "BodyType:[B Body:". I would >>> expect xml dom object or xml text there. >>> Any hints what the problem could be? >>> >>> 2008-07-19 14:26:12,141 [enerContainer-1] INFO TraceInterceptor >>> - ID-vchekan/3625-1216502771610/1-1 -> interceptor2 >>> Interceptor[Delegate(Pipeline[DeadLetterChannel[Delegate([EMAIL PROTECTED]), >>> RecipientList[log:org.apache.camel.DeadLetterChannel?level=error], >>> RedeliveryPolicy[maximumRedeliveries=6]], >>> DeadLetterChannel[Delegate(TraceInterceptor[To[activemq:vadim44]]), >>> RecipientList[log:org.apache.camel.DeadLetterChannel?level=error], >>> RedeliveryPolicy[maximumRedeliveries=6]]])] InOnly Properties:{} >>> Headers:{JMSXGroupID=null, JMSType=null, JMSCorrelationID=null, >>> JMSMessageID=ID:vchekan-3550-1216502210018-2:0:1:1:2, JMSExpiration=0, >>> JMSRedelivered=false, jdbc.columnCount=1, JMSDeliveryMode=2, >>> JMSPriority=4, JMSTimestamp=1216502224862, JMSReplyTo=null, >>> JMSDestination=queue://vadim33} BodyType:java.util.ArrayList >>> Body:[{body=some text}] >>> >>> 2008-07-19 14:26:12,188 [enerContainer-1] INFO TraceInterceptor >>> - ID-vchekan/3625-1216502771610/1-1 -> marshal1 >>> [EMAIL PROTECTED] >>> InOnly Properties:{CamelCauseException=null} >>> Headers:{JMSXGroupID=null, JMSType=null, JMSCorrelationID=null, >>> JMSMessageID=ID:vchekan-3550-1216502210018-2:0:1:1:2, JMSExpiration=0, >>> JMSRedelivered=false, jdbc.columnCount=1, JMSDeliveryMode=2, >>> JMSPriority=4, JMSTimestamp=1216502224862, JMSReplyTo=null, >>> JMSDestination=queue://vadim33} BodyType:java.util.ArrayList >>> Body:[{some text}] >>> >>> 2008-07-19 14:26:12,391 [enerContainer-1] INFO TraceInterceptor >>> - ID-vchekan/3625-1216502771610/1-1 -> to3 >>> To[activemq:vadim44] InOnly Properties:{CamelCauseException=null} >>> Headers:{JMSXGroupID=null, JMSType=null, JMSCorrelationID=null, >>> JMSMessageID=ID:vchekan-3550-1216502210018-2:0:1:1:2, JMSExpiration=0, >>> JMSRedelivered=false, jdbc.columnCount=1, JMSDeliveryMode=2, >>> JMSPriority=4, JMSTimestamp=1216502224862, JMSReplyTo=null, >>> JMSDestination=queue://vadim33} BodyType:[B Body: >>> >>> >>> -- >>> From RFC 2631: In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT >>> is explicitly specified >>> >> >> > >
