You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2010/05/23 17:00:26 UTC
[jira] Created: (WSCOMMONS-543) Change in r887108 breaks design of
org.apache.axis2.transport.base.datagram
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.
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, May 24, 2010 at 14:22, Hiranya Jayathilaka <hi...@gmail.com> wrote:
> On Mon, May 24, 2010 at 1:39 PM, Andreas Veithen
> <an...@gmail.com>wrote:
>
>> On Mon, May 24, 2010 at 09:56, Hiranya Jayathilaka <hi...@gmail.com>
>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> > Blog: http://techfeast-hiranya.blogspot.com
>> >
>>
>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Mon, May 24, 2010 at 1:39 PM, Andreas Veithen
<an...@gmail.com>wrote:
> On Mon, May 24, 2010 at 09:56, Hiranya Jayathilaka <hi...@gmail.com>
> 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?
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?
Thanks,
Hiranya
>
> > Thanks,
> > Hiranya
> >
> >
> > --
> > Hiranya Jayathilaka
> > Senior Software Engineer;
> > WSO2 Inc.; http://wso2.org
> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> > Blog: http://techfeast-hiranya.blogspot.com
> >
>
--
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, May 24, 2010 at 09:56, Hiranya Jayathilaka <hi...@gmail.com> 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.
> Thanks,
> Hiranya
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, May 24, 2010 at 06:23, Hiranya Jayathilaka <hi...@gmail.com> wrote:
> Andreas,
>
> On Mon, May 24, 2010 at 1:02 AM, Andreas Veithen
> <an...@gmail.com>wrote:
>
>> On Sun, May 23, 2010 at 20:58, Hiranya Jayathilaka <hi...@gmail.com>
>> wrote:
>> > Hi Andreas,
>> >
>> > On Sun, May 23, 2010 at 11:13 PM, Andreas Veithen <
>> andreas.veithen@gmail.com
>> >> wrote:
>> >
>> >> On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <
>> hiranya911@gmail.com>
>> >> 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."
>>
>
> The bottom line is, it acts as a template for transport protocol addresses.
> Isn't that what we want when it comes to sending back responses? We just
> need to hold on to the protocol address of the source machine, right?
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.
>> >
>> > 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.
>>
>> You should read the entire Javadoc:
>>
>> "It provides an immutable object used by sockets for binding,
>> connecting, or as returned values."
>>
>> "Socket" is a reference to OSI layer 4. Using SocketAddress in
>> org.apache.axis2.transport.base.datagram would thus result in a design
>> that makes these classes only appropriate as a basis for transports
>> that exchange messages directly over an OSI layer 4 protocol.
>
>
> While I agree with you on the theoretical definition of sockets, practically
> speaking, the SocketAddress class can be subclassed in ways that are not
> specific to the transport layer in the OSI model. BTW here's how the concept
> of Socket is defined in the javadocs:
>
> "This class implements client sockets (also called just "sockets"). A socket
> is an endpoint for communication between two machines."
>
> So the concept of sockets can be used to model virtually any protocol
> endpoint in Java.
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?
>> BTW, it's the first time that I heard somebody suggesting to create
>> new subclasses of SocketAddress (and that are not usable with
>> Socket#bind or Socket#connect). Do you know of anybody doing this?
>>
>
> Not that I know of. But if needed it can be done easily. As mentioned in the
> javadocs it is 'meant' to be subclassed. The SocketAddress class does not
> contain any methods either. So its implementation could be completely
> transport specific as desired by the developer.
>
>
>>
>> >> > 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.
>>
>> SocketAddress is OSI layer 4 specific...
>>
>
> Let's say we really got rid of the SocketAddress references from the base
> transport. What is the alternative you are suggesting for handling
> request-response scenarios with transports like UDP?
Using the right abstraction directly, namely OutTransportInfo. That
also solves the issue that the UDP transport uses two kinds of
OutTransportInfo instances.
> Thanks,
> Hiranya
>
>
>> >>
>> >> > 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) <
>> jira@apache.org
>> >> >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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> >> > Blog: http://techfeast-hiranya.blogspot.com
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Hiranya Jayathilaka
>> > Senior Software Engineer;
>> > WSO2 Inc.; http://wso2.org
>> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
>> > Blog: http://techfeast-hiranya.blogspot.com
>> >
>>
>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
BTW why is this issue on WSCOMMONS? Shouldn't this be on AXIS JIRA?
Thanks,
Hiranya
On Mon, May 24, 2010 at 9:53 AM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
> Andreas,
>
> On Mon, May 24, 2010 at 1:02 AM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> On Sun, May 23, 2010 at 20:58, Hiranya Jayathilaka <hi...@gmail.com>
>> wrote:
>> > Hi Andreas,
>> >
>> > On Sun, May 23, 2010 at 11:13 PM, Andreas Veithen <
>> andreas.veithen@gmail.com
>> >> wrote:
>> >
>> >> On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <
>> hiranya911@gmail.com>
>> >> 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."
>>
>
> The bottom line is, it acts as a template for transport protocol addresses.
> Isn't that what we want when it comes to sending back responses? We just
> need to hold on to the protocol address of the source machine, right?
>
>
>> >
>> > 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.
>>
>> You should read the entire Javadoc:
>>
>> "It provides an immutable object used by sockets for binding,
>> connecting, or as returned values."
>>
>> "Socket" is a reference to OSI layer 4. Using SocketAddress in
>> org.apache.axis2.transport.base.datagram would thus result in a design
>> that makes these classes only appropriate as a basis for transports
>> that exchange messages directly over an OSI layer 4 protocol.
>
>
> While I agree with you on the theoretical definition of sockets,
> practically speaking, the SocketAddress class can be subclassed in ways that
> are not specific to the transport layer in the OSI model. BTW here's how the
> concept of Socket is defined in the javadocs:
>
> "This class implements client sockets (also called just "sockets"). A
> socket is an endpoint for communication between two machines."
>
> So the concept of sockets can be used to model virtually any protocol
> endpoint in Java.
>
>
>> BTW, it's the first time that I heard somebody suggesting to create
>> new subclasses of SocketAddress (and that are not usable with
>> Socket#bind or Socket#connect). Do you know of anybody doing this?
>>
>
> Not that I know of. But if needed it can be done easily. As mentioned in
> the javadocs it is 'meant' to be subclassed. The SocketAddress class does
> not contain any methods either. So its implementation could be completely
> transport specific as desired by the developer.
>
>
>>
>> >> > 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.
>>
>> SocketAddress is OSI layer 4 specific...
>>
>
> Let's say we really got rid of the SocketAddress references from the base
> transport. What is the alternative you are suggesting for handling
> request-response scenarios with transports like UDP?
>
> Thanks,
> Hiranya
>
>
>> >>
>> >> > 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) <
>> jira@apache.org
>> >> >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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> >> > Blog: http://techfeast-hiranya.blogspot.com
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Hiranya Jayathilaka
>> > Senior Software Engineer;
>> > WSO2 Inc.; http://wso2.org
>> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
>> > Blog: http://techfeast-hiranya.blogspot.com
>> >
>>
>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
--
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Andreas,
On Mon, May 24, 2010 at 1:02 AM, Andreas Veithen
<an...@gmail.com>wrote:
> On Sun, May 23, 2010 at 20:58, Hiranya Jayathilaka <hi...@gmail.com>
> wrote:
> > Hi Andreas,
> >
> > On Sun, May 23, 2010 at 11:13 PM, Andreas Veithen <
> andreas.veithen@gmail.com
> >> wrote:
> >
> >> On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <
> hiranya911@gmail.com>
> >> 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."
>
The bottom line is, it acts as a template for transport protocol addresses.
Isn't that what we want when it comes to sending back responses? We just
need to hold on to the protocol address of the source machine, right?
> >
> > 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.
>
> You should read the entire Javadoc:
>
> "It provides an immutable object used by sockets for binding,
> connecting, or as returned values."
>
> "Socket" is a reference to OSI layer 4. Using SocketAddress in
> org.apache.axis2.transport.base.datagram would thus result in a design
> that makes these classes only appropriate as a basis for transports
> that exchange messages directly over an OSI layer 4 protocol.
While I agree with you on the theoretical definition of sockets, practically
speaking, the SocketAddress class can be subclassed in ways that are not
specific to the transport layer in the OSI model. BTW here's how the concept
of Socket is defined in the javadocs:
"This class implements client sockets (also called just "sockets"). A socket
is an endpoint for communication between two machines."
So the concept of sockets can be used to model virtually any protocol
endpoint in Java.
> BTW, it's the first time that I heard somebody suggesting to create
> new subclasses of SocketAddress (and that are not usable with
> Socket#bind or Socket#connect). Do you know of anybody doing this?
>
Not that I know of. But if needed it can be done easily. As mentioned in the
javadocs it is 'meant' to be subclassed. The SocketAddress class does not
contain any methods either. So its implementation could be completely
transport specific as desired by the developer.
>
> >> > 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.
>
> SocketAddress is OSI layer 4 specific...
>
Let's say we really got rid of the SocketAddress references from the base
transport. What is the alternative you are suggesting for handling
request-response scenarios with transports like UDP?
Thanks,
Hiranya
> >>
> >> > 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) <
> jira@apache.org
> >> >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: hiranya@wso2.com; Mobile: +94 77 633 3491
> >> > Blog: http://techfeast-hiranya.blogspot.com
> >> >
> >>
> >
> >
> >
> > --
> > Hiranya Jayathilaka
> > Senior Software Engineer;
> > WSO2 Inc.; http://wso2.org
> > E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> > Blog: http://techfeast-hiranya.blogspot.com
> >
>
--
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Andreas Veithen <an...@gmail.com>.
On Sun, May 23, 2010 at 20:58, Hiranya Jayathilaka <hi...@gmail.com> wrote:
> Hi Andreas,
>
> On Sun, May 23, 2010 at 11:13 PM, Andreas Veithen <andreas.veithen@gmail.com
>> wrote:
>
>> On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <hi...@gmail.com>
>> 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.
You should read the entire Javadoc:
"It provides an immutable object used by sockets for binding,
connecting, or as returned values."
"Socket" is a reference to OSI layer 4. Using SocketAddress in
org.apache.axis2.transport.base.datagram would thus result in a design
that makes these classes only appropriate as a basis for transports
that exchange messages directly over an OSI layer 4 protocol.
BTW, it's the first time that I heard somebody suggesting to create
new subclasses of SocketAddress (and that are not usable with
Socket#bind or Socket#connect). Do you know of anybody doing this?
>> > 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.
SocketAddress is OSI layer 4 specific...
>>
>> > 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) <jira@apache.org
>> >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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> > Blog: http://techfeast-hiranya.blogspot.com
>> >
>>
>
>
>
> --
> Hiranya Jayathilaka
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Andreas,
On Sun, May 23, 2010 at 11:13 PM, Andreas Veithen <andreas.veithen@gmail.com
> wrote:
> On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <hi...@gmail.com>
> 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) <jira@apache.org
> >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: hiranya@wso2.com; Mobile: +94 77 633 3491
> > Blog: http://techfeast-hiranya.blogspot.com
> >
>
--
Hiranya Jayathilaka
Senior Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Andreas Veithen <an...@gmail.com>.
On Sun, May 23, 2010 at 19:14, Hiranya Jayathilaka <hi...@gmail.com> 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.
> 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 :-)
> 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.
> Thanks,
> Hiranya
>
> On Sun, May 23, 2010 at 8:30 PM, Andreas Veithen (JIRA) <ji...@apache.org>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: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
Re: [jira] Created: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Andreas,
I didn't quite understand the problem caused by adding this dependency.
Could you please explain it a little more?
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. If not they can simply pass null. Or we can even introduce
a new receive method to the AbstractDatagramTransportListener class which
does not accept a SocketAddress argument. WDYT?
Thanks,
Hiranya
On Sun, May 23, 2010 at 8:30 PM, Andreas Veithen (JIRA) <ji...@apache.org>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: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
[jira] Assigned: (WSCOMMONS-543) Change in r887108 breaks design of
org.apache.axis2.transport.base.datagram
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen reassigned WSCOMMONS-543:
-----------------------------------------
Assignee: Andreas Veithen
> 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
> Assignee: Andreas Veithen
> Priority: Blocker
> Fix For: Transports 1.1
>
>
> The change in r887108 [1] introduced a dependency between the classes in org.apache.axis2.transport.base.datagram and SocketAddress. This badly breaks the design of these classes, 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.
[jira] Updated: (WSCOMMONS-543) Change in r887108 breaks design of
org.apache.axis2.transport.base.datagram
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen updated WSCOMMONS-543:
--------------------------------------
Description:
The change in r887108 [1] introduced a dependency between the classes in org.apache.axis2.transport.base.datagram and SocketAddress. This badly breaks the design of these classes, 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
was:
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
> 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 the classes in org.apache.axis2.transport.base.datagram and SocketAddress. This badly breaks the design of these classes, 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.
[jira] Resolved: (WSCOMMONS-543) Change in r887108 breaks design of
org.apache.axis2.transport.base.datagram
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen resolved WSCOMMONS-543.
---------------------------------------
Resolution: Fixed
Fixed as described above.
> 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
> Assignee: Andreas Veithen
> Priority: Blocker
> Fix For: Transports 1.1
>
>
> The change in r887108 [1] introduced a dependency between the classes in org.apache.axis2.transport.base.datagram and SocketAddress. This badly breaks the design of these classes, 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.
[jira] Commented: (WSCOMMONS-543) Change in r887108 breaks design
of org.apache.axis2.transport.base.datagram
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870454#action_12870454 ]
Andreas Veithen commented on WSCOMMONS-543:
-------------------------------------------
The proper solution for this issue is as follows: instead of letting the UDP code submit the SocketAddress to the abstract datagram classes (which then builds a DatagramOutTransportInfo instance from it), it should directly create the DatagramOutTransportInfo (with the right subclass, namely UDPOutTransportInfo), and submit that to the abstract datagram classes. Indeed, for Axis2, OutTransportInfo is the right abstraction to store information about the back channel. It is also interesting to see that since UDPOutTransportInfo extends DatagramOutTransportInfo, it both has a SocketAddress attribute and two attributes to store a hostname and port number. Usage of two different kinds of OutTransportInfo is also the cause for the code duplication in UDPSender#sendMessage.
> 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 the classes in org.apache.axis2.transport.base.datagram and SocketAddress. This badly breaks the design of these classes, 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.