As I guess you've determined, there is no way to do exactly what you 
are suggesting that is built into the code.  I doubt it will be 
added, as there is already a list of to-do items that are not being 
worked on at any noticeable rate.

The "standard" way to do something close to what you are proposing is 
to write one or more custom providers.  For all services using these 
providers, you can munge envelopes and context.

On 22 Jan 2003 at 7:33, Kurt Kavanaugh wrote:

> 
> Messaging services already have access to the SOAPContext for the 
> request (it's one of the method parameters), so they can use that.
> 
> [Kurt Kavanaugh] 
> 
> Understood. Respectfully, perhaps I am not making myself clear. I don't
> want to look at the content and context from within a service... I want
> too...
> 
> 
> -> server -> servlet( servletCtx ) -> MessageRouter ->[ invoke service ]
>                                            |
>                                           inspect( content, ctx )
> 
> So that I can provide value added for all services without having per
> service approach. For all service types, for messages both incoming and
> outgoing.
> 
> So something like....
> 
>         Provider provider;
>         if ( dd.getProviderType() == DeploymentDescriptor.PROVIDER_JAVA
> ) {
>           // Handle Java based services
>           provider = new org.apache.soap.providers.RPCJavaProvider();
>         } else if (dd.getProviderType() ==
>                    DeploymentDescriptor.PROVIDER_USER_DEFINED) {
>           // Handle user-defined providers
>           provider = ServerUtils.loadProvider(dd, reqCtx);
>         } else {
>           // Handle scripts
>           provider = new org.apache.soap.providers.RPCJavaProvider();
>         }
>         
>         provider.locate( dd, callEnv, call, call.getMethodName(),
> fullTargetID, 
>                          reqCtx );
> 
>         // new code or something like...
> 
>         Collection c = Handler.getHandlers();
>         Iterator it = c.iterator();
>         While (it.hasNext()) {
>            Handler h = (Handler)it.next();
>            h.invoke( reqCtx );
>         }
> 
>         provider.invoke( reqCtx, resCtx );
> 
> 
> 
> Have a set of init-paramaters
> 
>     <init-param>
>       <param-name>Handler</param-name>
>       <param-value>MyClass</param-value>
>     </init-param>
> 
> Where MyClass implements Handler
> 
> Interface Handler
> 
> Abstract void Invoke( SoapContext );
> 
> 
> 
> On 22 Jan 2003 at 5:11, Kurt Kavanaugh wrote:
> 
> > 
> > 
> > You can access SOAPContext as described at 
> > http://xml.apache.org/soap/docs/guide/migration.html.  Basically, you 
> > add an initial parameter to your method of type SOAPContext.
> > 
> > [Kurt Kavanaugh] 
> > 
> > Sweet. Is this for SOAP message types of RPC only?
> > 
> > On 21 Jan 2003 at 13:38, Kurt Kavanaugh wrote:
> > 
> > > 
> > > No.  The transport hook just gives you a reader (to read the SOAP 
> > > envelope) and writer (to write the possibly modified SOAP envelope).
> > > 
> > > [Kurt Kavanaugh] 
> > > 
> > > Thanks for the reply!
> > > 
> > > Just to complete my query... is there anyway at a global -
> > > request/response level to access the Soapcontext/properties? Like an
> > > Axis handler?
> > > 
> > > If not... Is there a potential for me joining the development force
> > and
> > > creating an interface like SoapContextListener( SoapContext ) and
> > having
> > > the same model of inclusion (ie. The InitParameter syntax ). I have
> > been
> > > looking at modifying the source code locally. Somehow I need to get
> > this
> > > done.
> > > 
> > > Just a thought... 
> > > 
> > > Thanks for reading and considering
> > > 
> > > On 21 Jan 2003 at 10:48, Kurt Kavanaugh wrote:
> > > 
> > > > 
> > > > 
> > > > [Kurt Kavanaugh] 
> > > > 
> > > > More specifically, Apache SOAP 2.x ( not Axis )
> > > > 
> > > > Is this possible?
> > > > 
> > > > Thanks
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > > 
> > > > 
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > > 
> > > > 
> > > 
> > > 
> > > Scott Nichol
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > 
> > > 
> > 
> > 
> > Scott Nichol
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > 
> > 
> 
> 
> Scott Nichol
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


Scott Nichol


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to