Keith,
That sounds very similar to what I had put together, though perhaps a
little more robust on the sending side. Perhaps your code would make a
better contribution than mine at this point.
Sam
Willard, Keith wrote:
Sam,
While I have not figured why the provided JMSTransport classes in
XFire do not work in my hands with more complex examples besides the
provided Echo example (namely they blow up in parsing the returned xml
after the channel has passed the InMessage back into the framework) I
have written an alternative set of JMS transport/channel classes
(separate for producer and consumer) that appears to work around the
problem.
In addition to working, these classes have the advantage of using
Jencks for connection/session pooling and the Spring JmsTemplate
classes on the producer (generally client) side and the
Jencks/ActiveMQ JCA container framework (as well as the Spring
JmsTemplate classes) on the consumer (generally server) side to do the
actual JMS sending and receiving work. So they don’t do much
themselves except interact with the XFire world but the channel gets
the benefit of an efficient pooled leak free JMS resource world. We
have used this combination of Jencks/Spring JmsTemplate before and
like it a lot better than working with the jms api’s directly.
These channel classes presently support three message exchange
patterns, a synchronous request/reply pattern using JMS queues, one
way queue messaging and one way topic messaging.
For the request reply pattern (that was most problematic with the
existing JMSTransport classes) the biggest change I made was to follow
the existing http client channel as an example (which worked with the
JAXB services) and block in the channel’s
send(MessageContext context, OutMessage message)method to receive the
response rather than having the client have a second thread and use an
onMessage() method to capture the return result. It does continue to
use the idea of a named response queue rather than temp queues.
In doing this I was following the approach taken by the XFire client
http channel (which workedJ).
Just changing things so the client response work was using the same
thread as the send was enough to cause the client side parsing
problems I was seeing to disappear.
--Keith
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
