You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gd...@macromedia.com> on 2001/08/31 20:43:52 UTC
Transport change
Take a look at the checkin I just did wrt transports, and let me know what
you think. I can always roll it back, but this will solve the problem Ryo
was having for the nonce.
Glen Daniels
Macromedia
http://www.macromedia.com/
Building cool stuff for web developers
Re: Transport change
Posted by Glen Daniels <gd...@macromedia.com>.
Well that's easily fixable - instead of keeping a static Transport object
per protocol, we can simply remember the class and create a new one for each
ServiceClient.
Personally, I think that's a good way to go, in that keeping transport
dependent state in the transport object is what it's designed for, and we
have precedent (TCP and HTTP transports) for that state including addressing
information. If we didn't do it that way, and could share Transport
objects, we'd need to set some connection-specific parameters which ARE
transport-specific, but COULDN'T live in the (sharable) Transport object,
and then you're back in the situation that Transport was built to get you
out of in the first place.
--G
----- Original Message -----
From: "Ryo Neyama" <ne...@trl.ibm.co.jp>
To: <ax...@xml.apache.org>
Sent: Saturday, September 01, 2001 1:40 AM
Subject: Re: Transport change
> Glen,
>
> I think it's not a good idea because ServiceClient class becomes
> thread-unsafe.
> "Transports" hashtable is a table for mapping between URL's protocol and
> Transport objects, right?
> The problem is the table transports is a class variable therefore settting
a
> specific URL into a Transport object in the table makes ServiceClient
class
> thread-unsafe. Even if we creates two ServiceClient objects for two
> threads, confusing URL could happen because URL comes from the static
table.
>
> Ryo Neyama @ IBM Research, Tokyo Research Laboratory
> Internet Technology
> neyama@trl.ibm.co.jp
>
> ----- Original Message -----
> From: "Glen Daniels" <gd...@macromedia.com>
> To: <ax...@xml.apache.org>
> Sent: Saturday, September 01, 2001 3:43 AM
> Subject: Transport change
>
>
> >
> > Take a look at the checkin I just did wrt transports, and let me know
what
> > you think. I can always roll it back, but this will solve the problem
Ryo
> > was having for the nonce.
> >
> > Glen Daniels
> > Macromedia
> > http://www.macromedia.com/
> > Building cool stuff for web developers
> >
> >
>
Re: Transport change
Posted by Ryo Neyama <ne...@trl.ibm.co.jp>.
Glen,
I think it's not a good idea because ServiceClient class becomes
thread-unsafe.
"Transports" hashtable is a table for mapping between URL's protocol and
Transport objects, right?
The problem is the table transports is a class variable therefore settting a
specific URL into a Transport object in the table makes ServiceClient class
thread-unsafe. Even if we creates two ServiceClient objects for two
threads, confusing URL could happen because URL comes from the static table.
Ryo Neyama @ IBM Research, Tokyo Research Laboratory
Internet Technology
neyama@trl.ibm.co.jp
----- Original Message -----
From: "Glen Daniels" <gd...@macromedia.com>
To: <ax...@xml.apache.org>
Sent: Saturday, September 01, 2001 3:43 AM
Subject: Transport change
>
> Take a look at the checkin I just did wrt transports, and let me know what
> you think. I can always roll it back, but this will solve the problem Ryo
> was having for the nonce.
>
> Glen Daniels
> Macromedia
> http://www.macromedia.com/
> Building cool stuff for web developers
>
>