Upon cleaning up the classes and the little bookstore JUnit driven example I am using I would be glad to share them, although I don't know what the best way to do that is since I am not a contributor on the XFire team.
The package name on the classes is a McKesson one at this point. I don't have an ant or maven build process for the test cases at present, am just using a small Eclipse project and manually grabbed the library dependencies from the XFire 1.2.4 release and the ServiceMix 3.1 release (to get the Jencks Geronimo transaction manager dependencies). These JMS channel classes have a compile dependency on the Spring JmsTemplate class but that doesn't induce any new compile time dependency since Spring is already in the XFire compile dependency stack, and the Jencks connection pooling, JCA container and ActiveMQ JCA adaptor classes are all injected via Spring at runtime so there is only a need for those frameworks at runtime. --Keith -----Original Message----- From: Sam Wilson [mailto:[EMAIL PROTECTED] Sent: Friday, April 13, 2007 9:51 AM To: [EMAIL PROTECTED] Subject: Re: [xfire-user] FW: problems with using JMSTransport and JAXB 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 --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
