First of all, can anyone tell me where to send posts that inquire about the
architecture? I cannot participate in the development effort (not that
anyone would ask me :)) so I don't know if I should post on the developer's
mailing list.
I have been playing with creating a JMSTransport class. I got it working
using mainly through code that I got from the Wrox book 'AXIS: Next
Generation Java SOAP'.
But there is a major architectural miss here as far as I can tell. Please
someone correct me if I am wrong.
In that book, the client needs to do a call.setTransport(new JMSTransport())
in order to have JMSTransport process the message as the pivot handler. But
there seems to be no way to get the endpoint URL that was specified by the
client in order to have the JNDI JMS names (QueueConnectionFactory, Queue)
passed in. There is also a static Call.setTransportForProtocol method that
looked like it might work that would eliminate that need for the
setTransport to be called on an individual Call basis, i.e.:
Call.setTransportForProtocol("jms", JMSTransport);
call.setTargetEndpointAddress("jms://qcfName/qName");
<deployment...>
<handler name="JMSDispatcher" type="java:JMSSender">
<parameters....>
</handler>
<transport name="jms" pivot="JMSDispatcher"/>
</deployment>
Then hopefully JMSTransport would have access to the URL in its overridden
setupMessageContextImpl() method based on the MessageContext.TRANS_URL
property.
Unfortunately, using a "jms" protocol gives a malformedURL exception so that
doesn't work.
There are other issues too, such as the positioning of the call to
setTransport() is crucial in the client code. If it happens after the
setTargetEndpointAddress, different code gets executed (after looking thru
the source code)...
Anyway, am I missing something? Is there really a good architecture here for
plugging in custom transports?
Regards,
Rick Fishman
TECHNICAL ARCHITECTURE SERVICES
Blue Cross Blue Shield of Florida
DCC 6-5 203, Ext. 51987
e-mail: [EMAIL PROTECTED]
Phone: (904) 905-1987
Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this e-mail
message. Any personal comments made in this e-mail do not reflect the views of Blue
Cross Blue Shield of Florida, Inc.
