Hi Andreas, On Sun, May 23, 2010 at 11:13 PM, Andreas Veithen <[email protected] > wrote:
> On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <[email protected]> > wrote: > > Hi Andreas, > > > > I didn't quite understand the problem caused by adding this dependency. > > Could you please explain it a little more? > > Having a dependency between the classes in > org.apache.axis2.transport.base.datagram and SocketAddress is a > violation of the design as would be a dependency between > AbstractTransportListener and javax.jms.ConnectionFactory. > I disagree. ConnectionFactory is a JMS specific class. It has no reason to be in a high level interface like AbstractTransportListener. But SocketAddress is a more general class that can be used to model any transport address. Here's the introduction of the SocketAddress class from the javadocs: "This class represents a Socket Address with no protocol attachment. As an abstract class, it is meant to be subclassed with a specific, protocol dependent, implementation." As you can see it is abstract and exists at a very high level. It is not bound to any transport protocol implementation. So IMO there is nothing wrong in having a dependency to such a high level interface from the base transport module. > > SocketAddress is a high level abstract class. The widely used > > InetSocketAddress class is derived from that. IMO almost any transport > can > > make use of that. > > No, the pipe transport in Synapse is based on > org.apache.axis2.transport.base.datagram and for this one, > SocketAddress has no meaning. > > > If not they can simply pass null. > > Yes, we could also add a javax.jms.ConnectionFactory attribute in > AbstractTransportListener and let all transport except the JMS > transport set it to null :-) > As I've already mentioned, ConnectionFactory is JMS specific whereas SocketAddress is generic. These two cannot be compared with each other. > > > Or we can even introduce > > a new receive method to the AbstractDatagramTransportListener class which > > does not accept a SocketAddress argument. WDYT? > > I haven't looked into the reasons for the appearance of SocketAddress > in that code, so I don't know yet what is the correct way to get rid > of it. > If I understood correct a SocketAddress is used to keep track of the source address for each message/datagram. This address is then used to send responses back. So it has a very good reason to be in the base transport. Since it is abstract each transport implementation can have their own implementations of the SocketAddress to model transport specific source addresses (although in UDP transport we seem to be using the default InetSocketAddress implementation which works fine in case of UDP). Given these reasons I don't think we have to completely get rid of this from the base transport. If we must we can add a new receive method which does not care about source addresses. This method can be used by transports like the Synapse pipe transport. Thoughts? Thanks, Hiranya > > Thanks, > > Hiranya > > > > On Sun, May 23, 2010 at 8:30 PM, Andreas Veithen (JIRA) <[email protected] > >wrote: > > > >> Change in r887108 breaks design of > org.apache.axis2.transport.base.datagram > >> > --------------------------------------------------------------------------- > >> > >> Key: WSCOMMONS-543 > >> URL: > https://issues.apache.org/jira/browse/WSCOMMONS-543 > >> Project: WS-Commons > >> Issue Type: Bug > >> Components: Transport > >> Reporter: Andreas Veithen > >> Priority: Blocker > >> Fix For: Transports 1.1 > >> > >> > >> The change in r887108 [1] introduced a dependency between > >> AbstractDatagramTransportListener and SocketAddress. This badly breaks > the > >> design of the classes in org.apache.axis2.transport.base.datagram, since > >> they are not only used for UDP (which is the only derived transport that > >> uses SocketAddress). See also [2] and [3]. This needs to be fixed for > the > >> next release. > >> > >> [1] http://svn.apache.org/viewvc?rev=887108&view=rev > >> [2] http://markmail.org/thread/ancuyeuxefi6ttnn > >> [3] http://markmail.org/message/nls3mpg2g4ec3uq5 > >> > >> -- > >> This message is automatically generated by JIRA. > >> - > >> You can reply to this email to add a comment to the issue online. > >> > >> > > > > > > -- > > 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
