2008/4/16, runr <[EMAIL PROTECTED]>:
>
> Roman,
>
> Thanks for your response. It was quite helpful. I had been working with
> Camel 1.2 still and it had not worked as you described - no reply was being
> sent to the JMSReplyTo queue after the EJB method invocation.
Well - as you noticed there are a lot of changes since 1.2 ;)
> I went ahead and upgraded to Camel 1.3 and retried, obtaining different (and
> improved) behavior. Your answer works well when the EJB invocation returns
> whatever is expected to be received by the JMS client that is awaiting the
> response.
>
> In my use case scenario, the JMS client was expecting a custom message
> object to be returned, whereas the EJB methods I was invoking return either
> a double or void.
>
> So, I modified the JmsToEjbMethod Processor that was invoked before the EJB
> invocation, to store the received custom message object as an Exchange
> property, and I then retrieved and updated this custom message object in the
> EjbMethodToJms Processor that was invoked upon return from the EJB
> invocation. After updating the custom message object with the response
> info, I replace the in Message's body with my custom message object using
> in.setBody(). The custom message object is then automatically returned by
> Camel to the JMS client. So my route looks like this:
>
>
> from("jms:inQueue").process(new
>
> JmsToEjbMethod()).to("bean:ejbProxy").process(new EjbMethodToJms());
>
> In this scenario, I needed to preserve some information across the EJB
> method's invocation. In my JmsToEjbMethod Processor, I added a property to
> the Exchange to hold this information (i.e., the custom message object). Is
> that an appropriate usage of an Exchange property?
This is exactly what properties are for.
Basically we have two different things: headers (on messages) and
properties (on exchanges). Headers tries to be sent via
endpoint-specific technology to a recepient (like properties on JMS
message). They are usually lost at the endpoint (response JMS message
doesn't have the same properties that request).
In case of properties they they are not represented (usually) using
underlying technology, so they are not lost. If you want to keep some
information until you explicitely remove it properties are your
choice.
> Again, thanks!
You are welcome,
Roman
