Return-Path: Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list soap-dev@xml.apache.org Received: (qmail 91033 invoked from network); 14 Aug 2000 17:45:22 -0000 Received: from host127.vignette.com (HELO hard.vignette.com) (207.8.7.254) by locus.apache.org with SMTP; 14 Aug 2000 17:45:22 -0000 Received: from vignette.com (hq2519.vignette.com [10.17.60.223]) by hard.vignette.com (8.10.1/8.10.1) with ESMTP id e7EHib217915 for ; Mon, 14 Aug 2000 12:44:37 -0500 Message-ID: <3998308B.6A4DC27A@vignette.com> Date: Mon, 14 Aug 2000 12:46:51 -0500 From: Rich Johns X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: soap-dev@xml.apache.org Subject: Re: 1st pass: http provider gets context References: Content-Type: multipart/alternative; boundary="------------147C0D6182D0F55E2B4D53FB" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N --------------147C0D6182D0F55E2B4D53FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jean-Noel Gadreau wrote: > > > The only problem I see (from my quick glance) with your implementation is when you have a scope > other than 'request'. What I don't like is that if 2 clients perform a call on the same object, > you will need to be very careful in the way you handle the 'setSoapContext', because otherwise, I > would see the following happening: > I see the problem for 'application' scope, yes. But isn't it true that client 1 and client 2 each have a separtae HttpSession? If that is the case, then shouldn't it work for 'session' scope as well? There's only one instance of a provider per session in this case. For 'application' scope, yes, the onus is on the provider class to manage synchronization. > > setSoapContext(context1); > setSoapContext(context2); > callFunction1(); > callFunction2(); > > instead of > > setSoapContext(context1); > callFunction1(); > setSoapContext(context2); > callFunction2(); > > My first thought would probably be to favor an approach where you pass the context as a parameter > (say the first parameter) of the method. I wanted to avoid this to preserve loose coupling between the router and the provider. However, I'm guessing there are many cases where the provider classes must be created specifically for their soap duty anyway. and in such a case, maybe the importance of loose coupling is diminished. > > > I think many people will need to have access to some information from the context (be it HTTP > context or other). I think that it should be possible to use Apache-SOAP in 2 ways : completely > "non-intrusive", where you just take an existing class and plug it in, and the "Apache-SOAP-aware" > way, where you know you will be running through the SOAP engine, but you want to use more > information. That makes sense. From a web application point of view, it sort of boils down to what your url endpoint is, ie., /soap/servlet/RPCServletWithContext, or, /soap/servlet/RPCServlet. Avoiding a monolithic implementation where you pay for everything whether you use it or not is a good thing. Under this philosophy, would the BSF stuff be refactored into specialized classes? > > > As for putting your change in what I am doing, I am not sure I will have time for it right now but > it should not be hard to put it in a special "EnvelopeProcessor". I will try to get another > version out soon. No problem, especially since you're not comfortable with the changes. If we (all of us) can decide on an approach for this 'specialized RPCCallWithContext' behavior, I will gladly do the work. > thanks for taking time. --------------147C0D6182D0F55E2B4D53FB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Jean-Noel Gadreau wrote:

 

The only problem I see (from my quick glance) with your implementation is when you have a scope other than 'request'. What I don't like is that if 2 clients perform a call on the same object, you will need to be very careful in the way you handle the 'setSoapContext', because otherwise, I would see the following happening:
 

I see the problem for 'application' scope, yes. But isn't it true that client 1 and client 2 each have a
separtae HttpSession? If that is the case, then shouldn't it work for 'session' scope as well? There's
only one instance of a provider per session in this case.

For 'application' scope, yes, the onus is on the provider class to manage synchronization.

 
setSoapContext(context1);
setSoapContext(context2);
callFunction1();
callFunction2();

instead of

setSoapContext(context1);
callFunction1();
setSoapContext(context2);
callFunction2();

My first thought would probably be to favor an approach where you pass the context as a parameter (say the first parameter) of the method.

I wanted to avoid this to preserve loose coupling between the router and the provider. However, I'm guessing
there are many cases where the provider classes must be created specifically for their soap duty anyway. and
in such a case, maybe the importance of  loose coupling is diminished.
 

I think many people will need to have access to some information from the context (be it HTTP context or other). I think that it should be possible to use Apache-SOAP in 2 ways : completely "non-intrusive", where you just take an existing class and plug it in, and the "Apache-SOAP-aware" way, where you know you will be running through the SOAP engine, but you want to use more information.

That makes sense. From a web application point of view, it sort of boils down to what your url endpoint
is, ie.,   /soap/servlet/RPCServletWithContext, or, /soap/servlet/RPCServlet.
Avoiding a monolithic implementation where you pay for everything
whether you use it or not is a good thing. Under this philosophy, would the BSF stuff be refactored into specialized
classes?
 

As for putting your change in what I am doing, I am not sure I will have time for it right now but it should not be hard to put it in a special "EnvelopeProcessor". I will try to get another version out soon.

No problem, especially since you're not comfortable with the changes. If we (all of us) can decide on an
approach for this 'specialized RPCCallWithContext' behavior, I will gladly do the work.
 


thanks for taking time.
  --------------147C0D6182D0F55E2B4D53FB--