ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noel Gadreau <>
Subject RE: 1st pass: http provider gets context
Date Mon, 14 Aug 2000 16:50:14 GMT
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:


instead of


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

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.

Software Engineer, ActivCard Inc.( )
Tel (main): 510-574-0100
Tel (direct): 510-574-1736

-----Original Message-----
From: Rich Johns []
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

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
rationale, and details. (I have attached the 2 files I changed:
and There are very few changes and I believe they are


1. In

    - 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

    - 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

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.


View raw message