On Mon, May 24, 2010 at 14:22, Hiranya Jayathilaka <[email protected]> wrote: > On Mon, May 24, 2010 at 1:39 PM, Andreas Veithen > <[email protected]>wrote: > >> On Mon, May 24, 2010 at 09:56, Hiranya Jayathilaka <[email protected]> >> wrote: >> > 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. >> >> That is the whole point: SocketAddress is right for UDP and thus >> should be used in org.apache.axis2.transport.udp. For the classes in >> org.apache.axis2.transport.base.datagram, it is not the right >> abstraction, and OutTransportInfo should be used instead. >> >> > 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? >> >> Anything that the subclass of AbstractDatagramTransportListener >> decides to store in there. UDPListener will store a SocketAddress (or >> keep the hostname/port attributes that already exist in >> UDPOutTransportInfo). Any other subclass of >> AbstractDatagramTransportListener that supports the concept of a back >> channel will provide its own subclass of OutTransportInfo. >> > > OK, now this is starting to make sense. So as far as the UDP transport is > concerned, references to SocketAddress will NOT be removed. It will be only > removed from the base transport, is that correct?
Yes, the UDP transport can of course have whatever dependencies it needs. > So in the base transport what kind of object are we going to pass to the > receive method? Also do you think a datagram transport will have a > requirement for storing something other than a SocketAddress in the > OutTransportInfo? No, the concrete transport implementation would actually pass the OutTransportInfo object to the base classes. > Thanks, > Hiranya > > >> >> > 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 >> > >> > > > > -- > 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 >
