Liav, No, setting those on the NormalizedMessage should be fine actually. Do you think you could provide us with some more details on how you configured your endpoints (xbean.xml snippets) and give us an idea on what your Marshaler class looks like?
Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/2/16 liav ezer <[email protected]>: > Hi Gert, > > I am adding those property to the NormalizedMessage headers: > > > MessageExchange me; > > me = > context.getDeliveryChannel().createExchangeFactory().createExchange(getDefaultMep()); > > NormalizedMessage in = me.createMessage(); > > in.setProperty(name, value); > Should it be differently? Maybe i should add it as an attachment? > > Thanks. > > On Mon, Feb 16, 2009 at 9:54 AM, Gert Vanthienen > <[email protected]>wrote: > >> Liav, >> >> The Exchange properties are mainly used by the framework to manage the flow >> of exchanges (e.g. correlation, routing, ...). If you want to send some >> information using headers, you should use the NormalizedMessage headers for >> that. I think the RetryRequest exception is actually something Jetty >> specific to manage threads and continuations (cfr. >> http://docs.codehaus.org/display/JETTY/Continuations). >> >> Regards, >> >> Gert >> >> >> Liav Ezer wrote: >> >>> Hi, >>> >>> I'm setting some properties on the exchange properties map in the consumer >>> marshaler. I can see it passes through my camel & reaches all the way to >>> the >>> SedaFlow. >>> >>> Inside the SedaFlow we perform enqueuePacket(me) & rollback all the way to >>> the HttpConsumerEndpoint (through the JBIContainer) - there i get an >>> exception while trying to perform: >>> boolean result = cont.suspend(to); ...line 237 inside process() >>> The exception's cause is org.mortbay.jetty.RetryRequest. >>> >>> & indeed there is another try to enqueue the packet in the SedaFlow - this >>> time it's without the properties we set. >>> >>> Why does the process fails to send the packet the first try & why does it >>> looses its property map in the second? >>> >>> Thanks. >>> >>> >> >> >
