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>
Subject: Trace
To: axis-c-dev@ws.apache.org
Message-ID: 
 <OFFB6E0682.9833F414-ON80256EE7.00307DD2-80256EE7.00315056@uk.ibm.com>
From: John Hawkins <HAWKINSJ@uk.ibm.com>
Date: Thu, 5 Aug 2004 09:58:38 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII


Hi Folks,

More observations and questions -

We are currently trying to track down a problem and therefore require
trace. This made us look at trace !

1) Trace seems to be used mainly for error messages rather than e.g.
tracing entry and exit of methods - Fair enough.
2) Dynamic versus static initialisation of trace: Trace is currently a
compile time option. This is not really very good for dealing with a
customer situation where I can't really expect them to stop their system
and start it again with a different version of our libraries. We have
looked at trace code and concluded that it would be reasonably simple to
put in the conf file a flag to say whether you wanted trace on or not. This
would mean that the trace methods would always be called but the trace
object (AxisTrace) would look at the flag and consider whether to actually
do anything or not e.g.
AxisTrace::trace(...)
{
       if(traceOn)
      {
            tracestuff
      }
}

Now, I understand that calling a method when you might do nothing in it is
not great but that's why I pointed out that really trace is not really full
blown trace rather we use it more as an error message writer. In which case
the trace is only used when something goes wrong and thus no performance
overhead in the main line of code.

Any thoughts - if not then we'll go ahead and implement the changes asap.

thankyou,
John.