Willem.Jiang wrote
>
> If you are using camel-cxf, you can using the option "synchronous=true" in
> your camel-cxf endpoint to let it call the service in synchronized mode.
>
Hi Willem,
I'm not normally using camel-cxf in these scenarios, although I guess I
could add an intermediate endpoint a
If you are using camel-cxf, you can using the option "synchronous=true" in
your camel-cxf endpoint to let it call the service in synchronized mode.
Willem
--
View this message in context:
http://cxf.547215.n5.nabble.com/JMS-Message-Correlation-in-CXF-2-3-tp4830121p5605948.html
Sent from the cxf-
Hi Jens,
I think this can not be done easily in the async case as we are using
the blocking method jmsTemplate.receiveSelected(replyToDestination,
messageSelector)
which would not be suitable for the async case. We could of course start
a thread to listen for the answer. I will check if this c
Hi Christian,
sorry for the slow reponse, I got sidetracked a little.
Anyway, here's a header dump of a request message without the conduit
parameters:
MQGET of message number 1
Message descriptor
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 1
Expiry : -1 Feedback :
This is exactly what CXF is doing if you do not set the conduitId
properties.
This is from the JmsConduit. I removed some lines in between:
---
jmsTemplate.send(jmsConfig.getTargetDestination(), messageCreator);
correlationId = messageCreator.getMessageID();
final String messageSelector = "JM
This is how I have implemented req/res on top of WMQ - but should really
work on any JMS impl.:
doSend( producer, requestMessage );
correlationId = requestMessage.getJMSMessageID();
String selector = "JMSCorrelationID = '" + correlationId + "'"; //hard to
read on mail - but it quotes the ' char
Obj
Hi Jens,
would be really great to get these dumps. I still hope we can make the
Websphere MQ case just work without adding a config option. As we are
setting up a message selector for the message id on receive this
normally should work. If not it must be a speciality of the IBM MQ system.
Ch
Hi Christian,
I can get those dumps, too, yes, but it won't work regardless.
With WebSphere MQ you always (!) need to use an "ID:" selector prefix when
working with JMS, or the selector won't match.
Jens
Christian Schneider wrote:
>
> Hi Jens,
>
> that is expected .. at least for the new CXF
Hi Jens,
that is expected .. at least for the new CXF version. If you specify a
conduitIdSelector then you tell CXF to use that selector when receiving
and to also set a correlation id that matches this pattern.
You have to leave it off too enable message id as correlation id. Can
you also try
Hi Christian,
it's a synchronous call, but it doesn't work because if you use the
conduitSelector CXF generates its own correlation ID which means the JMS
template will try to use that for correlation instead of the message ID.
Here's a sample message dump.
Request:
MQGET of message number 1
*
The selector for the correlation id seems to be only used for
synchronous calls. Is that the case for your project or do you call the
client asynchronously? In the sync case I would expect the code to work.
Can you do some dumps of the messages going in and out of cxf and on the
queues?
It wou
Hi Christian,
unfortunately, no. I have never been able to correlate anything with
WebSphere MQ without using the conduitIdSelectorPrefix. (That's what the
option is for, I presume?)
Regards,
Jens
Christian Schneider wrote:
>
> Hi Jens,
>
> thanks for the explanation. Now I understand your us
Hi Jens,
thanks for the explanation. Now I understand your use case. You need the
separate replyToDestination to tell the server to send to its local queue.
While I think this should be rather hidden from the client I can imagine
that it is necessary.
So I think you should be able to just lea
Hi Christian,
they must be set to different names because the server is listening on a
different queue at a different queue manager, and it doesn't know the local
queue manager my application is talking to. My application sends its
messages to a local queue that automatically forwards to the other
Re: JMS Message Correlation in CXF 2.3+
Christian Schneider
Hi Jens,
why do you set replyDestination and replyToDestination to different
names? I don´t think that this can work.
The JMSConduit will always specify the replyDestination in the message
it sends out. So the server should always send the reply there.
When receiving the JMSConduit will use t
Hi Christian,
that won't work, primarily because I'm not allowed to use temporary queues
(company policy) and the server is listening on a remote queue manager, so
if I leave out replyToDestination it won't know where to send the reply.
Jens
Christian Schneider wrote:
>
> Hi Jens,
>
> why don
Hi Jens,
why don´t you simply leave out replyDestination, replyToDestination,
useConduitIdSelector, conduitIdSelectPrefix.
Then cxf will use a temp queue for replies and the correlation should
still work. Can you try this with the newest CXF?
Christian
Am 30.09.2011 15:25, schrieb Jens:
T
This is what worked with 2.2 (angle brackets replaced to get through Nabble):
[bean id="jmsConfig"
class="org.apache.cxf.transport.jms.JMSConfiguration"]
[property name="connectionFactory" ref="jmsConnectionFactory"/]
[property name="targetDestination"
value="queue:///out.queue?targetCli
Can you post your config?
Christian
Am 30.09.2011 14:00, schrieb Jens:
Hi Christian,
thanks for your reply.
I had a look at the code, too. I guess my problem is that I need to a
conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
correlate anything at all.
My attempts to h
Hi Christian,
thanks for your reply.
I had a look at the code, too. I guess my problem is that I need to a
conduitSelectorPrefix with WebSphere MQ ("ID:"), otherwise CXF cannot
correlate anything at all.
My attempts to hack the conduit to support this have unfortunately not been
successful so fa
Hi jens,
sorry for the delay. I just created a testcase for this as I found none
that was testing this case.
See below for the algorithm to determine the correlation id to send out.
So if you do not set a conduitSelectorPrefix and use a sync call and do
not set useConduitIdSelector then it sh
Hi,
am I assuming correctly that the silence on this topic means it's not
currently possible to do this?
Seeing as the functionality was not ported to 2.3 in CXF-2760, does filing a
new issue on this make sense?
If I interpret the current code correctly, CXF uses the same semi-automatic
approach
Let me try to phrase the question differently. It looks like the CXF JMS
transport by default correlates the correlationId, ie. the client sets a
correlationId on the request that it expects to be returned as the
correlationId of the response.
In my case I have a server that returns the messageId
In version 2.1 and 2.2 CXF had a property useMessageIDAsCorrelationID on the
JMSConfiguration to adjust how the client correlates JMS messages. The
property wsa introduced in CXF-2760, and in that issue Willem mentions that
in 2.3 (and later, I presume) CXF has a new way to achieve the same result.
25 matches
Mail list logo
