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 77352 invoked from network); 14 Aug 2000 16:55:29 -0000 Received: from mail.activcard.com (HELO hub1.hub.activcard.com) (207.93.240.18) by locus.apache.org with SMTP; 14 Aug 2000 16:55:29 -0000 Received: from usexchg1.activcard.com (USEXCHG1 [192.168.133.9]) by hub1.hub.activcard.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id N60FYTW6; Mon, 14 Aug 2000 09:56:20 -0700 Received: by USEXCHG1 with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Aug 2000 09:50:16 -0700 Message-ID: From: Jean-Noel Gadreau To: "'soap-dev@xml.apache.org'" Subject: RE: 1st pass: http provider gets context Date: Mon, 14 Aug 2000 09:50:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0060F.B8E73E54" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0060F.B8E73E54 Content-Type: text/plain; charset="windows-1252" I have looked at your implementation and I have some remarks. For the implementation with my proposed architecture, it would be possible to write a "RPCCallWithContextProcessor" (long name :-) that works exactly like you propose it. We could even imagine to have the RPCRouter be changed so that it can either take a context (for use in RPCCallWithContextProcessor) or just null in the case of the current processor. 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: 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 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. 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. Jean-Noel ============= Jean-Noel GADREAU Software Engineer, ActivCard Inc.(http://www.activcard.com ) E-mail: jngadreau@activcard.com Tel (main): 510-574-0100 Tel (direct): 510-574-1736 -----Original Message----- From: Rich Johns [mailto:rjohns@vignette.com] Sent: Monday, August 14, 2000 6:12 AM To: soap-dev Subject: 1st pass: http provider gets context I've taken a stab at the first pass implementation of handing off context to service providers over http. My experiments absolutely require it, so I'd like to get this on the table for discussion. The concept is that a service provider might require context information that is normally available to a servlet. The changes I made try to honor the concept of a loose coupling between the soap-layer and the provider class. Here is a list of the changes I made, PLEASE see the code for comments rationale, and details. (I have attached the 2 files I changed: RPCRouterServlet.java and RPCRouter.java). There are very few changes and I believe they are unobtrusive. -------------------------------------change list------------------------------------------------------ 1. In RPCRouterServlet.java: - passing in the context to rpcRouter.invoke(...) // invoke the method on the target object. Pass into the rpcRouter a // context that can optionally be handed to the service provider. resp = rpcRouter.invoke (call, targetObject, makeHttpContext( req, context ) ); - added a method called makeHttpContext which packages up the HttpServletRequest and the ServletContext in a HashMap. 2. In the RPCRouter.java: - only for provider types of PROVIDER_JAVA I attempt to set the context on the provider instance: // before invoking call, offer context to target object setContext( targetObject, context ); result = new Bean (m.getReturnType (), m.invoke (targetObject, args)); - added a setContext method (please see code for comments and details) --------------------------------------------end change list------------------------------------------ Jean-Noel, I almost put these changes in your code, as I believe the refactoring you are doing is going in the right direction, but I decided to wait until you get farther down the road. Actually, if you agree with these changes perhaps you could pick them up, they are'nt extensive at all. If nothing else, I hope this first pass attempt gets the issue of provider classes and context on the table. I realize my approach is specific for Http, but I'm not sure what context means for other transports. Thanks ------_=_NextPart_001_01C0060F.B8E73E54 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable RE: 1st pass: http provider gets context

I have looked at your implementation and I have some = remarks. For the implementation with my proposed architecture, it would = be possible to write a "RPCCallWithContextProcessor" (long = name :-) that works exactly like you propose it. We could even imagine = to have the RPCRouter be changed so that it can either take a context = (for use in RPCCallWithContextProcessor) or just null in the case of = the current processor.

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:

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 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.

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.

Jean-Noel
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736

-----Original Message-----
From: Rich Johns [mailto:rjohns@vignette.com]
Sent: Monday, August 14, 2000 6:12 AM
To: soap-dev
Subject: 1st pass: http provider gets context


I've taken a stab at the first pass implementation of = handing
off context to service providers over http. My = experiments
absolutely require it, so I'd like to get this on = the table for
discussion.

The concept is that a service provider might require = context information
that is normally available to a servlet. The changes = I made try to honor
the concept of a loose coupling between the = soap-layer and the provider
class. Here is a list of the changes I made, = PLEASE  see the code for comments
rationale, and details. (I have attached the 2 files = I changed: RPCRouterServlet.java
and RPCRouter.java). There are very few changes and = I believe they are unobtrusive.

-------------------------------------change
list------------------------------------------------------

1. In RPCRouterServlet.java:

    - passing in the context to = rpcRouter.invoke(...)

      // invoke the method = on the target object. Pass into the rpcRouter a
      // context that can = optionally be handed to the service provider.
      resp =3D = rpcRouter.invoke (call, targetObject, makeHttpContext( req, context ) = );

   - added a method called makeHttpContext = which packages up the HttpServletRequest and
     the ServletContext in a = HashMap.


2. In the RPCRouter.java:

    - only for provider types of  = PROVIDER_JAVA I attempt to set the context on the
      provider = instance:

     // before invoking call, = offer context to target object
     setContext( targetObject, = context );
     result =3D new Bean = (m.getReturnType (), m.invoke (targetObject, args));

   - added a setContext method (please see = code for comments and details)

--------------------------------------------end = change
list------------------------------------------

Jean-Noel, I almost put these changes in your code, = as I believe the refactoring you are doing
is going in the right direction, but I decided to = wait until you get farther
down the road. Actually, if you agree with these = changes perhaps you could pick them up, they are'nt

extensive at all. If nothing else, I hope this first = pass attempt gets the issue of provider classes

and context on the table. I realize my approach is = specific for Http, but I'm not sure what
context means for other transports.

Thanks

------_=_NextPart_001_01C0060F.B8E73E54--