Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <20040722032227.59681.qmail@web40608.mail.yahoo.com>
Date: Wed, 21 Jul 2004 20:22:27 -0700 (PDT)
From: Samisa Abeysinghe <samisa_abeysinghe@yahoo.com>
Subject: Re: Removal of prefix from HeaderBlock
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
In-Reply-To: 
 <OFD3088AC8.E0A283E2-ON80256ED8.003ABFEC-80256ED8.0042F465@uk.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Adrian Dick <adrian.dick@uk.ibm.com> wrote:
> 
> 
> 
> 
> Hi,
> 
> Having just moved up to the 1.2 release of the Axis C++ code, we've found
> that it is no longer possible to specify a prefix on HeaderBlocks.  This
> causes us significant problem, as the backend server (not an Axis C++
> server) expects the HeaderBlocks to be of a specific prefix - not the one
> generated during serialization.
> 
> We are currently using the following 2 methods of adding SOAPHeaderBlocks
>    From within the stub
>    stub->createSOAPHeaderBlock
>    From within a handler
>    IHandlerSoapSerializer->createHeaderBlock
> For both methods it was previously possible to assign a prefix to the
> HeaderBlock either during construction or through the setPrefix method.
> 
> Why have the methods to assign a prefix been removed from HeaderBlock, and
> in turn the createSOAPHeader methods in Call and Stub?
> 
> The only comment I can see on this change is in HeaderBlock.cpp in the
> commented out setPrefix method:
>    The prefix should be decided by the Serializer at runtime
> Surely, this is wrong! It should be decided by the Serializer at runtime,
> only if one has not been specified.
> 

Sounds like the prefix is required as a parameter.
Is it possible to add the older api back to the code?

One idea; As more people are trying to use Axis C++ project, it is not a good idea to drop API
calls all the sudden, even if they have problems. 
Rahter Axis C++ team need to adopt a 'deprecate' methodology where older APIs are phased out
gradually. 
However, in this case it is not a problem of phasing out; rhather keeping it to make the API
flexible enough for developers.

Thanks,
Samisa...

> As this is affecting us now, we would appreciate a speedy response.
> 
> Thanks,
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
> 
> 


__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/