Return-Path: <Sylvain.StGermain@cognos.com>
Mailing-List: contact axis-user-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list axis-user@xml.apache.org
Received: (qmail 59192 invoked from network); 14 Mar 2002 22:03:54 -0000
Received: from nomad.cognos.com (HELO sotr0085.cognos.com) (205.210.232.62)
  by daedalus.apache.org with SMTP; 14 Mar 2002 22:03:54 -0000
Received: by sotr0085.cognos.com with Internet Mail Service (5.5.2653.19)
	id <G85TLWAS>; Thu, 14 Mar 2002 17:00:49 -0500
Message-ID: <FB15E670DA55D51185350008C786514A03088B21@sottexch1.cognos.com>
From: "St-Germain, Sylvain" <Sylvain.StGermain@cognos.com>
To: axis-user@xml.apache.org
Subject: RE: [server-config.wsdd] <parameter name="sendMultiRefs" value="f
		alse "/>
Date: Thu, 14 Mar 2002 17:00:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


Understand.  However, the fact that currently I am not being able to play
with the Call object is my major issue.  I ultimately need the ability to
play with it outside the Stub.  I agree that the header stuff probably
belong more to the service than the call though.  

I guess I am simply looking for an alternative until we have a real support
for header.   

This being said +1 for a public setOption() that allows to setup the Call
from outside of the Stub.

Sylvain.


-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Thursday, March 14, 2002 3:11 PM
To: axis-user@xml.apache.org
Subject: RE: [server-config.wsdd] <parameter name="sendMultiRefs"
value="f alse "/>


Making the getCall method public doesn't do any good.  Well, it might do
SOME good.  getCall gives you a Call object, but that Call object would
never be used in a stub invocation.  The only good it does is if you call
methods (like setOption!) that affect low-level objects that hang around
longer than the Call object.

The proper thing MIGHT be to have some of these methods on the service
rather than the stub, but we'll have to think about it a bit.

Russell Butek
butek@us.ibm.com


"St-Germain, Sylvain" <Sylvain.StGermain@cognos.com> on 03/14/2002 01:33:23
PM

Please respond to axis-user@xml.apache.org

To:    axis-user@xml.apache.org
cc:
Subject:    RE: [server-config.wsdd] <parameter name="sendMultiRefs" value
       ="f  alse "/>




I tend to agree with you but in the mean time it is impossible for someone
to set the options without hacking it in the Stub class.  I have the same
problem with seting the Call's soap header.

I've allways avoided to ask the following question, but here it is:

Could we make the getCall() method public?

so we can overcome the current Axis limitations regarding header stuff and
properties/options (among other thing)

(ouch)
Sylvain.



-----Original Message-----
From: Russell Butek [mailto:butek@us.ibm.com]
Sent: Thursday, March 14, 2002 2:11 PM
To: axis-user@xml.apache.org
Subject: RE: [server-config.wsdd] <parameter name="sendMultiRefs"
value="f alse "/>


You don't.  A new Call object is instantiated for every invocation, so
there is no Call object per Stub.  I'm considering putting a _setOption
method on the Stub that forwards the setOption to the Call once it's
instantiated, but I haven't decided whether that's the right thing to do.
It's an easy addition, so it's probably the wrong thing to do (aren't they
all?).

Russell Butek
butek@us.ibm.com


"St-Germain, Sylvain" <Sylvain.StGermain@cognos.com> on 03/14/2002 12:49:56
PM

Please respond to axis-user@xml.apache.org

To:    axis-user@xml.apache.org
cc:
Subject:    RE: [server-config.wsdd] <parameter name="sendMultiRefs" value
       ="f  alse "/>



How do you get to the Call object from the Stub?

Sylvain.

-----Original Message-----
From: Simon McClenahan [mailto:simon.mcclenahan@stellent.com]
Sent: Thursday, March 14, 2002 10:34 AM
To: axis-user@xml.apache.org
Subject: RE: [server-config.wsdd] <parameter name="sendMultiRefs"
value="false "/>


On the client you set an option on the Call.