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 2002/10/15 16:28:39 UTC
Stubs moving to single-threadedness
Hi folks!
As discussed last week both on the list and in person with Sam & Tom, I'd like to switch the stubs back to the way they used to be, namely each stub having a single Call object which gets reused. So multiple threads can share a Service/Locator, but each stub should only be used by one thread. This is very intuitive, I think, and has several advantages:
1) Simplicity. The code in the stubs would become much cleaner and smaller, making reading and debugging easier
2) Ease of use. It becomes possible to rely on state changes in the stub, which makes stub.addHeader(), stub.getCall(), etc. possible
3) (related to 2) This would enable a richer future design for dealing with SOAP extensions in a user-friendly manner
I asked for comments on this last week, but didn't hear anything. I'd like to move forward with this - can I get a +1?
--Glen
Re: Stubs moving to single-threadedness
Posted by Richard Sitze <rs...@us.ibm.com>.
Glen,
if this is a significant change, +1 to work through the issues on a
branch.
-1 to changing the head.
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Glen Daniels <gd...@macromedia.com>
10/15/2002 09:28 AM
Please respond to axis-dev
To: "'Axis-Dev (E-mail)'" <ax...@xml.apache.org>
cc:
Subject: Stubs moving to single-threadedness
Hi folks!
As discussed last week both on the list and in person with Sam & Tom, I'd
like to switch the stubs back to the way they used to be, namely each stub
having a single Call object which gets reused. So multiple threads can
share a Service/Locator, but each stub should only be used by one thread.
This is very intuitive, I think, and has several advantages:
1) Simplicity. The code in the stubs would become much cleaner and
smaller, making reading and debugging easier
2) Ease of use. It becomes possible to rely on state changes in the stub,
which makes stub.addHeader(), stub.getCall(), etc. possible
3) (related to 2) This would enable a richer future design for dealing
with SOAP extensions in a user-friendly manner
I asked for comments on this last week, but didn't hear anything. I'd
like to move forward with this - can I get a +1?
--Glen
Re: Stubs moving to single-threadedness
Posted by Davanum Srinivas <di...@yahoo.com>.
+1
-- dims
--- Glen Daniels <gd...@macromedia.com> wrote:
>
> Hi folks!
>
> As discussed last week both on the list and in person with Sam & Tom, I'd like to switch the
> stubs back to the way they used to be, namely each stub having a single Call object which gets
> reused. So multiple threads can share a Service/Locator, but each stub should only be used by
> one thread. This is very intuitive, I think, and has several advantages:
>
> 1) Simplicity. The code in the stubs would become much cleaner and smaller, making reading and
> debugging easier
>
> 2) Ease of use. It becomes possible to rely on state changes in the stub, which makes
> stub.addHeader(), stub.getCall(), etc. possible
>
> 3) (related to 2) This would enable a richer future design for dealing with SOAP extensions in a
> user-friendly manner
>
> I asked for comments on this last week, but didn't hear anything. I'd like to move forward with
> this - can I get a +1?
>
> --Glen
=====
Davanum Srinivas - http://xml.apache.org/~dims/
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com