Hi Tom, all:
IMO, there should be exactly *one* "extra" API on the generated class, and
that thing should give you access to all the Axis2-specific functionality.
This could be done in several ways:
- 1 -
class StubAPI {
public MessageContext getMessageContext();
...etc (Axis APIs)...
}
class Stub {
private StubAPI _stub;
public StubAPI _getStub() {
return _stub
};
}
class MyStub extends Stub
- 2 -
class Stub {
public MessageContext getMessageContext();
...etc (Axis APIs)...
}
class MyStub { // DOES NOT EXTEND STUB
public Stub _stub = new Stub();
// OR
private Stub _stub = new Stub();
public Stub _getStub() { return _stub: }
}
-------------
This way you say stuff like:
myStub._stub.getMessageContext();
instead of:
myStub._getMessageContext();
This allows us to use as many APIs as we want without worrying about
cluttering the namespace of the actual generated stub class.
Thoughts?
--Glen
----- Original Message -----
From: "Tom Jordahl" <[EMAIL PROTECTED]>
To: <[email protected]>; "Srinath Perera" <[EMAIL PROTECTED]>
Sent: Tuesday, July 26, 2005 2:46 PM
Subject: RE: [Axis2]transport and rest support for the stubs
Guys,
Just a quick note on this, you have to make sure that *all* of the
support APIs on the stub class start with "_" (underscore). Otherwise
if a service has a method named "setTransportInfo", bad things may
happen.
Yes, we did get this wrong in Axis 1.x. :-{
--
Tom Jordahl
Macromedia Server Development
-----Original Message-----
From: Srinath Perera [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 23, 2005 11:47 AM
To: [email protected]
Subject: [Axis2]transport and rest support for the stubs
hi All;
Shall we add the followoing two methods to the stubs and call the
corresponsing methods of the call object.
1) This will let the transport behaviour to be controlled
public void setTransportInfo(
String senderTransport,
String listenerTransport,
boolean useSeparateListener)
throws AxisFault {
....
}
2) add public setDoREST(true){..} to allow the rest support
Thanks
Srinath
