Forum Home » Fuse Distributions » Fuse Message Broker

Thread: Consuming Message from Out temp Queue and others questions

This question is not answered. Helpful answers available: 2. Correct answers available: 1.

Permlink Replies: 1 - Last Post: Jan 30, 2012 11:30 AM Last Post By: davsclaus

Posts: 11
Registered: 09/10/11
Consuming Message from Out temp Queue and others questions
Posted: Jan 22, 2012 5:15 PM
  Click to reply to this thread Reply

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!

Posts: 1,893
Registered: 10/14/08
Re: Consuming Message from Out temp Queue and others questions
Posted: Jan 30, 2012 11:30 AM   in response to: johnwalker in response to: johnwalker
  Click to reply to this thread Reply
Ad 1)

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

from foo
to JMS (request/reply)

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.

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.