No. Amila did that change to pass information about the back channel > to these abstract classes. Axis2 defines an interface for this type of > information, namely OutTransportInfo. If you look at the various > implementations of that interface, you can see that in general it is > lot more than just the protocol address of the source machine. UDP is > an exception here because it is connectionless. >
Well the whole purpose of capturing the SocketAddress is to put it in the OutTransportInfo. Currently it is stored in a DatagramOutTransportInfo. Then, why JMS uses javax.jms.Destination, and not > java.net.SocketAddress? And why Axis2 uses > org.apache.axis2.addressing.EndpointReference, and not > java.net.SocketAddress? > Just because you can doesn't mean you have to. Protocols like JMS and HTTP have requirements that cannot be fulfilled by commonly available implementations of the SocketAddress interface. It is much easier to use an abstraction which has the knowledge of the application layer protocol to deal with such transports. But for a simple protocol like UDP, SocketAddress is good enough. Besides neither JMS nor HTTP have anything to do with the AbstractDatagramTransportListener. Theoretically though one can use an HTTP specific implementation of the SocketAddress class to represent a HTTP address. Using the right abstraction directly, namely OutTransportInfo. That > also solves the issue that the UDP transport uses two kinds of > OutTransportInfo instances. > So what do you plan to keep in the OutTransportInfo instead of the SocketAddress? Thanks, Hiranya -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
