axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Memory for headerblocks
Date Tue, 10 Aug 2004 12:29:28 GMT

Hi Folks,

Can some one help me understand the design here please.

Deletion of Soap headerblocks ->

Given this bit of handler code (which is a fairly obvious thing to do in a
handler )

             BasicNode *pChildNode;
             BasicNode *pChildNodeValue;

             pChildNode = hdrBlock.createChild(ELEMENT_NODE);

             pChildNodeValue = hdrBlock.createChild(CHARACTER_NODE);

             delete pChildNode;    // ************************ //

When I put "delete pChildNode" at the end of the code snippet, the
<myprefix:accountId> node did not show up in the TCP/IP trace.  If I did
have it there, the node came out.

So, this is something that I would expect NOT to happen. Why aren't we
deleting the headerblocks is the question? What is a user supposed to do in
this situation. If I'm thinking straight they are going to have to keep a
list of their added headerblocks outside of their handler and then know
when to delete them ? If this is true then its real yucky The code for
SoapHeader destructor reads ->
     * header blocks are not deleted here any more. Its the responsibility
     * either a handler or stub etc to delete any header block created by
    list<IHeaderBlock*>::iterator itCurrHeaderBlock=

    while(itCurrHeaderBlock != m_headerBlocks.end())
        delete *itCurrHeaderBlock;

So, I can see that maybe if you are in a stub and you create the header
block then you might want to reuse the header block? So, perhaps we should
have a smarter SoapHeader destructor? One that looks at a flag which tells
it where it was created? I know this is also yuck but it gets me out of
this handler based memory problem.

Any thoughts?


View raw message