Vjeran,

Take this as an idea how to set call parameters without touching the generated stubs:

-----
Shantanu,

With Axis handlers I do it as follows:

Creating class CustomService:

public class CustomService extends Service {

   private Integer timeout = null;
   private SimpleChain reqHandlers = null;
   private SimpleChain respHandlers = null;

public Call createCall() throws ServiceException {
org.apache.axis.client.Call call = (org.apache.axis.client.Call) super.createCall();


       if (this.getTimeout() != null) {
           call.setTimeout(this.getTimeout());
       }

       if (this.getReqHandlers() != null || this.getRespHandlers() != null) {

call.setClientHandlers(this.getReqHandlers(), this.getRespHandlers());
}
return call;
}
....


The createCall() method is called by the stub during invocation of your method.

Usage of the stub:
        CustomService cservice = new CustomService();
        cservice.setTimeout(timeoutInteger);
        cservice.setReqHandlers(reqChain);

        XYZStub stub = new XYZStub(uri, cservice);
        stub.method1();

Hope this help.
Yves

On Friday 06 August 2004 10:14, Shantanu Sen wrote:

What is the preferred way of adding client side handlers given the
following constraints:

I only have the generated stub class - I instantiate it using reflection
and invoke the relevant method. So, I cannot do a
ServiceFactory.createService and then set the handlerinfochain etc as shown
in the jaxrpchandler sample and as recommended by the JAX-RPC spec.

Also, I cannot use the client side wsdd - I need to set the handlers
programmatically.

So, I was tinkering with the following approach. I already have a custom
EngineConfigureationFactory which I use to set my custom transport when
invoking a Web Service using an Axis client. I can try to reuse this class
to set the WSDDJAXRPCHandlerInfoChain on the service.

1. Set a custom EngineConfigurationFactory using
properties.put("axis.EngineConfigFactory", "myfactory")

2. myfactory returns a custom EngineConfiguration (MyClientEngineConfig) on
the getClientEngineConfig() call.

3. The MyClientEngineConfig extends SimpleProvider

In this class I need to somehow set the WSDDJAXRPCHandlerInfoChain on the
Service. I have not been successful yet. Here is the class
===========================
public static class MyClientEngineConfig extends SimpleProvider {

WSDDJAXRPCHandlerInfoChain handlerInfoChain;

public MyClientEngineConfig() {
deployTransport("http", new SimpleTargetedChain(new MyHttpTransport()));
}

public void configureEngine(AxisEngine engine) throws
ConfigurationException { super.configureEngine(engine);

// just test it for now
ArrayList listOfHandlerInfos = new ArrayList();
WSDDJAXRPCHandlerInfo info = new WSDDJAXRPCHandlerInfo();
info.setHandlerClassName("MyClientHandler");
listOfHandlerInfos.add(info);

handlerInfoChain = new WSDDJAXRPCHandlerInfoChain();
handlerInfoChain.setHandlerInfoList(listOfHandlerInfos);

}

public SOAPService getService(QName qname) throws ConfigurationException {
SOAPService s = super.getService(qname);
if (s != null) {
s.setOption(Constants.ATTR_HANDLERINFOCHAIN, handlerInfoChain);
} else {
// Create SOAP Service here and set the option ? Is this a good approach?
}

return s;
}
===================

Is there a better way of doing this? The ideal thing would have been to set
the handler(s) on the MyClientEngineConfig and let it do it's job. But
unfortunately, SimpleProvider only deals with Axis handlers - not JAX-RPC
handlers.

Alternatively I can create a XML fragment that contains the content of
client-config.wsdd then use WSDDDocument to read it in the configureEngine
(basically similar to what the FileProvider does). This should also work.
But this also seems rather convoluted - why do I have to read a doc and
setup my service configuration every time I make a call? I can probably
cache the WSDDDocument for all calls through a specific client. But is
there a better approach?

Any suggestions will be highly appreciated.

Thanks,
Shantanu





Vjeran Marcinko wrote:

I'm a bit confused now, or maybe you thought that I'm speaking of server
side, while I'm talking about client stubs ... Maybe you can help me through
this example.

Let's say generated client stub that implements MyServicePort that exposes
all needed remote actions can be instantiated like this :
Stub stub = new SoapMyServiceBindingStub(portAddress, null);
Problem is that I cannot use this class above as client singleton (by
whatever means of instantiating it - Spring way is popular currently) and to
be used shared for all users of my web application, since class above
requires username/password set beforehand like :
stub.setUsername(username);
stub.setPassword(username);
before calling any remote action (exposed in MyServicePort interface).

And now comes the problem - if simultaneous users use my web application,
and want to execute some remote actions using this shared client stub, that
means that they have to set this username/password on this same instance,
thus making it unusable for simultaneous usage.

Am I right ?

-Vjeran

----- Original Message ----- From: "Martin Olsson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 22, 2004 10:20 AM
Subject: Re: Client stub as singleton service impossible?





You need to set the scope parameter to "application" in your deployment
descriptor, this will force Axis to create just one instance of your web
services class and then reuse this instance for all additional users.


regards, martin olsson


Vjeran Marcinko wrote:


Hi folks.

I'm using Axis 1.1 client stub generated by WSDL2Java ant task. I'm


pretty


happy about it, but there is one problem.
My web application serves for many users to log in and perform some


actions


on remote SOAP service, and I would like this client stub to be


singleton


service exposing these remote actions. Problem is that each user of my
application has (as normal) different username/password, that is mapped


to


SOAP username/passwords sent inside SOAP request by this client stub,


but


since this username/password is suposed to be set on client stub before
calling remote actions (thus SOAP login is sent during each forecoming
requests), that practicaly forces me to use separate stubs for each user


of


my webapp, and not one mutual singleton stub per application as desired?

Has anyone experiences similar requirement, and solved it somehow ?

Regards,
Vjeran









Reply via email to