Consuming Message from Out temp Queue and others questions

[johnwalker]

Hi,

I'd like to use a jms queue in InOut mode.

In this mode, the Out queue is a temp queue dynamically generated by Camel.

1) I'd like to know if there is a way to get the message coming back from the Out queue so I can transform it before it goes back to the caller.

Or should I use the Request/Reply EIP for that ?

2) Assuming I bind many from end points to a jms queue (let say RS and WS), is there a way, at the time the message is consumed from the In, is there a way to detect whether the message have been sent with CXF-WS or CXF-RS ?

Or should I add something in the header of the message between the endpoint and the in jms queue ?

3) Is it possible to use Camel as a JDBC proxy ? In others word, to put Camel between ,let says an Oracle Client and an Oracle DB so that the some validation can be done: For example, validating the XML a Client want to persist into the DB

4) Is it possible to use Camel as a network sniffer for all Camel supported endpoint ? So that Camel can be placed between 2 systems to identify all the exchanges happening between these 2 systems. I guess it is impossible yet, but is it feasible ?

5) Any examples of Message transformation using Woodstox ?

Thank You!

J.

[davsclaus]

Ad 1)

Yes you can transform the message after the request/reply over JMS,

from foo

  to JMS (request/reply)

  transform

When the route ends, the result is what is returned to the caller of foo.

Ad 2)

When Camel creates an Exchange (eg when a new message is received into Camel) it stores the from endpoint uri as its creator. So you can use that to detect which endpoint created it.

http://fusesource.com/docs/router/2.8/apidoc/org/apache/camel/Exchange.html#getFromEndpoint()

Ad 3)

That is tough. You would need something a like a JDBC spy driver, which is a JDBC driver wrapper, which intercepts on the JDBC driver level. You would need something alike that for proxying JDBC. Camel does not offer something like that out of the box.

Ad 4)

For the transports which naturally supports this is feasible, such as all TCP / HTTP based transports. Likewise for JMS you can use Camel to bridge two different JMS brokers etc. An example where this is harder is that JDBC example beforehand.

Ad 5)

I would assume having woodstock on the classpath would allow Camel to transform XML using the XSLT component. There is no specific camel-woodstock component.