You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by John Hawkins <HA...@uk.ibm.com> on 2004/08/05 10:58:38 UTC
Trace
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.
Re: Trace
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Do we need something complex as Log4cpp?
Isn't the current AxisTrace class (with few improvements) good enough for this?
Samisa...
--- damitha kumarage <da...@opensource.lk> wrote:
> Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
> and see
> whether we can plug it to Axis C++.
>
> Thanks
> damitha
>
> On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
> >
> >
> > +1 that was the solution we came up with a few minutes after me sending
> > this note :-)
> >
> >
> > John Hawkins
> > IBM,
> > AspectX Architect,
> > C web services client dev.
> >
> > +44 (0) 1962 817131
> >
> >
> >
> >
> > Samisa Abeysinghe
> > <samisa_abeysingh
> > e@yahoo.com> To
> > Apache AXIS C Developers List
> > 05/08/2004 11:53 <ax...@ws.apache.org>
> > cc
> >
> > Please respond to Subject
> > "Apache AXIS C Re: Trace
> > Developers List"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Sounds good to me.
> >
> > As the method body of 'trace' is excuted only if the trace option is set
> > this would not be a
> > problem for individual cases.
> > However, depending on how often the method is called, there could be a
> > performance hit. (but may
> > be this is negligible at times)
> >
> > To let those who wish to go without the trace at all, we could use both the
> > dynamic and static
> > options in combination. (i.e. have both compiler option and conf file
> > option)
> >
> > Thanks,
> > Samisa...
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> > http://promotions.yahoo.com/new_mail
> >
> >
> >
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Namespace changes committed
Posted by sanjaya singharage <sa...@opensource.lk>.
Namespaces have been added to the Axis c++ code base. The WSDL2Ws tool has
been changed accordingly.
The following namespace macros are defined in GDefine.h
===========================================
#define AXIS_CPP_NAMESPACE_START namespace axiscpp {
#define AXIS_CPP_NAMESPACE_END }
/*
The following is necessary for the skeletons and stubs to be built
*/
namespace axiscpp {}
#define AXIS_CPP_NAMESPACE_USE using namespace axiscpp;
#define AXIS_CPP_NAMESPACE_PREFIX axiscpp::
========================
All .h and .cpp files necessary to build the AxisSever and AxisClient
components are wrapped by the namespace macros hence including them in the
axiscpp namespace.
In components other than the AxisServer and AxisClient the
AXIS_CPP_NAMESPACE_USE is used where necessary .
thanks,
sanjaya.
Re: Trace
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 from me.
Sanjiva.
----- Original Message -----
From: "John Hawkins" <HA...@uk.ibm.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Tuesday, August 10, 2004 9:28 PM
Subject: Re: Trace
>
>
>
>
> So the question is does anyone object to us putting in an AspectC++ trace
> into the build? It will be optional so you don't have to put it into the
> code if you don't want.
>
> John Hawkins
>
>
>
>
>
> John
> Hawkins/UK/IBM@IB
> MGB To
> "Apache AXIS C Developers List"
> 06/08/2004 10:39 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Roshan,
>
> Entry and exit trace:
> This is where, at the start of every method - you put in trace to say that
> you are entering that method with the parameters that are going into that
> method e.g.
> myMethodName(char* mymethodparam)
> { entryTrace("myMethodName", myMethodParam);
>
> }
>
> exit trace is the opposite of that i.e. when the method is exited (only
> when exited cleanly however, if there is an exception then you do not
trace
> this as an exit but put in exception tracing e.g.
>
>
> myMethodName(char* mymethodparam)
> { entryTrace("myMethodName", myMethodParam);
>
> {
> // throwing an exception here
> // no EXIT trace required but will trace the exception
> traceException("exceptionID plus other useful information",
> exception);
>
>
> }
>
> exitTrace("myMethodName", NULL);
> return NULL;
> }
>
> Creation of entry and exit trace could be done using AspectC+
> (http://www.aspectc.org). Then the code writer sees none of the entry and
> exit trace thus saving code clutter. (There may be legal issues for us in
> IBM using this so we are wary at the moment but urgently looking into it).
>
>
> In terms of general trace - I would expect that to be whereever some
useful
> information is around and needs to be traced. Again ALL trace is switch
> offable at the runtime if not required.
>
>
>
> re: use of log4cpp. I think I don't care too much about either using this
> system or adding in our own. With aspects you can simply create another
> aspect that uses log4cpp instead of our own if that's peoples preference.
>
>
>
>
>
>
>
> John Hawkins
>
>
>
>
>
> Roshan
> Weerasuriya
> <roshan@opensourc To
> e.lk> Apache AXIS C Developers List
> <ax...@ws.apache.org>
> 06/08/2004 10:08 cc
>
> Subject
> Please respond to Re: Trace
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
> hi John,
>
> > How does the community feel about putting in entry and exit trace?
>
> What do you mean by entry and exit trace? You mean the entry point and
> the exit point of the problematic situation or something else?
>
> >we can
> > put it in as a build time option ie. write a program to put it in
> > automatically when building. This is the least error prone way of doing
> it.
>
> Also what do you mean by "write a program to put it in automatically
> when building" ?
>
> In my openion, if the trace provides information to describe the
> situation well, the community would be ok of it. The amount of stuff put
> to the trace (certainly only the necessory once), doesn't cause any
> issue, because it is just to describe the situation well. So if you need
> those then I guess you could certainly put them. Adding them will not
> cause any issues on performance etc, only a bunch of details will be
> caused to print at exceptional situations. But if the trace is not only
> used at exceptional situations, but also at normal situations may be
> just to log details at runtime, then the amount put in the trace might
> cause performance issues.
>
> Roshan
>
>
>
>
> On Fri, 2004-08-06 at 14:02, John Hawkins wrote:
> >
> >
> > How does the community feel about putting in entry and exit trace?
> > This is essential for the production level of code that we require. we
> can
> > put it in as a build time option ie. write a program to put it in
> > automatically when building. This is the least error prone way of doing
> it.
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
>
> > damitha kumarage
>
> > <damitha@opensour
>
> > ce.lk>
> To
> > Apache AXIS C Developers List
>
> > 06/08/2004 07:33 <ax...@ws.apache.org>
>
> >
> cc
> >
>
> > Please respond to
> Subject
> > "Apache AXIS C Re: Trace
>
> > Developers List"
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
> > and see
> > whether we can plug it to Axis C++.
> >
> > Thanks
> > damitha
> >
> > On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
> > >
> > >
> > > +1 that was the solution we came up with a few minutes after me
sending
> > > this note :-)
> > >
> > >
> > > John Hawkins
> > > IBM,
> > > AspectX Architect,
> > > C web services client dev.
> > >
> > > +44 (0) 1962 817131
> > >
> > >
> > >
> > >
> >
> > > Samisa Abeysinghe
> >
> > > <samisa_abeysingh
> >
> > > e@yahoo.com>
> > To
> > > Apache AXIS C Developers List
> >
> > > 05/08/2004 11:53 <ax...@ws.apache.org>
> >
> > >
> > cc
> > >
> >
> > > Please respond to
> > Subject
> > > "Apache AXIS C Re: Trace
> >
> > > Developers List"
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> > >
> > >
> > >
> > > Sounds good to me.
> > >
> > > As the method body of 'trace' is excuted only if the trace option is
> set
> > > this would not be a
> > > problem for individual cases.
> > > However, depending on how often the method is called, there could be a
> > > performance hit. (but may
> > > be this is negligible at times)
> > >
> > > To let those who wish to go without the trace at all, we could use
both
> > the
> > > dynamic and static
> > > options in combination. (i.e. have both compiler option and conf file
> > > option)
> > >
> > > Thanks,
> > > Samisa...
> > >
> > >
> > > --- John Hawkins <HA...@uk.ibm.com> wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > New and Improved Yahoo! Mail - Send 10MB messages!
> > > http://promotions.yahoo.com/new_mail
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
>
Re: Trace
Posted by damitha kumarage <da...@opensource.lk>.
OK Let's do it
damitha
On Tue, 2004-08-10 at 21:28, John Hawkins wrote:
>
>
> So the question is does anyone object to us putting in an AspectC++ trace
> into the build? It will be optional so you don't have to put it into the
> code if you don't want.
>
> John Hawkins
>
>
>
>
>
> John
> Hawkins/UK/IBM@IB
> MGB To
> "Apache AXIS C Developers List"
> 06/08/2004 10:39 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Roshan,
>
> Entry and exit trace:
> This is where, at the start of every method - you put in trace to say that
> you are entering that method with the parameters that are going into that
> method e.g.
> myMethodName(char* mymethodparam)
> { entryTrace("myMethodName", myMethodParam);
>
> }
>
> exit trace is the opposite of that i.e. when the method is exited (only
> when exited cleanly however, if there is an exception then you do not trace
> this as an exit but put in exception tracing e.g.
>
>
> myMethodName(char* mymethodparam)
> { entryTrace("myMethodName", myMethodParam);
>
> {
> // throwing an exception here
> // no EXIT trace required but will trace the exception
> traceException("exceptionID plus other useful information",
> exception);
>
>
> }
>
> exitTrace("myMethodName", NULL);
> return NULL;
> }
>
> Creation of entry and exit trace could be done using AspectC+
> (http://www.aspectc.org). Then the code writer sees none of the entry and
> exit trace thus saving code clutter. (There may be legal issues for us in
> IBM using this so we are wary at the moment but urgently looking into it).
>
>
> In terms of general trace - I would expect that to be whereever some useful
> information is around and needs to be traced. Again ALL trace is switch
> offable at the runtime if not required.
>
>
>
> re: use of log4cpp. I think I don't care too much about either using this
> system or adding in our own. With aspects you can simply create another
> aspect that uses log4cpp instead of our own if that's peoples preference.
>
>
>
>
>
>
>
> John Hawkins
>
>
>
>
>
> Roshan
> Weerasuriya
> <roshan@opensourc To
> e.lk> Apache AXIS C Developers List
> <ax...@ws.apache.org>
> 06/08/2004 10:08 cc
>
> Subject
> Please respond to Re: Trace
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
> hi John,
>
> > How does the community feel about putting in entry and exit trace?
>
> What do you mean by entry and exit trace? You mean the entry point and
> the exit point of the problematic situation or something else?
>
> >we can
> > put it in as a build time option ie. write a program to put it in
> > automatically when building. This is the least error prone way of doing
> it.
>
> Also what do you mean by "write a program to put it in automatically
> when building" ?
>
> In my openion, if the trace provides information to describe the
> situation well, the community would be ok of it. The amount of stuff put
> to the trace (certainly only the necessory once), doesn't cause any
> issue, because it is just to describe the situation well. So if you need
> those then I guess you could certainly put them. Adding them will not
> cause any issues on performance etc, only a bunch of details will be
> caused to print at exceptional situations. But if the trace is not only
> used at exceptional situations, but also at normal situations may be
> just to log details at runtime, then the amount put in the trace might
> cause performance issues.
>
> Roshan
>
>
>
>
> On Fri, 2004-08-06 at 14:02, John Hawkins wrote:
> >
> >
> > How does the community feel about putting in entry and exit trace?
> > This is essential for the production level of code that we require. we
> can
> > put it in as a build time option ie. write a program to put it in
> > automatically when building. This is the least error prone way of doing
> it.
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
>
> > damitha kumarage
>
> > <damitha@opensour
>
> > ce.lk>
> To
> > Apache AXIS C Developers List
>
> > 06/08/2004 07:33 <ax...@ws.apache.org>
>
> >
> cc
> >
>
> > Please respond to
> Subject
> > "Apache AXIS C Re: Trace
>
> > Developers List"
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
> > and see
> > whether we can plug it to Axis C++.
> >
> > Thanks
> > damitha
> >
> > On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
> > >
> > >
> > > +1 that was the solution we came up with a few minutes after me sending
> > > this note :-)
> > >
> > >
> > > John Hawkins
> > > IBM,
> > > AspectX Architect,
> > > C web services client dev.
> > >
> > > +44 (0) 1962 817131
> > >
> > >
> > >
> > >
> >
> > > Samisa Abeysinghe
> >
> > > <samisa_abeysingh
> >
> > > e@yahoo.com>
> > To
> > > Apache AXIS C Developers List
> >
> > > 05/08/2004 11:53 <ax...@ws.apache.org>
> >
> > >
> > cc
> > >
> >
> > > Please respond to
> > Subject
> > > "Apache AXIS C Re: Trace
> >
> > > Developers List"
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> > >
> > >
> > >
> > > Sounds good to me.
> > >
> > > As the method body of 'trace' is excuted only if the trace option is
> set
> > > this would not be a
> > > problem for individual cases.
> > > However, depending on how often the method is called, there could be a
> > > performance hit. (but may
> > > be this is negligible at times)
> > >
> > > To let those who wish to go without the trace at all, we could use both
> > the
> > > dynamic and static
> > > options in combination. (i.e. have both compiler option and conf file
> > > option)
> > >
> > > Thanks,
> > > Samisa...
> > >
> > >
> > > --- John Hawkins <HA...@uk.ibm.com> wrote:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > New and Improved Yahoo! Mail - Send 10MB messages!
> > > http://promotions.yahoo.com/new_mail
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
>
>
Re: Trace
Posted by John Hawkins <HA...@uk.ibm.com>.
So the question is does anyone object to us putting in an AspectC++ trace
into the build? It will be optional so you don't have to put it into the
code if you don't want.
John Hawkins
John
Hawkins/UK/IBM@IB
MGB To
"Apache AXIS C Developers List"
06/08/2004 10:39 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Trace
Developers List"
Hi Roshan,
Entry and exit trace:
This is where, at the start of every method - you put in trace to say that
you are entering that method with the parameters that are going into that
method e.g.
myMethodName(char* mymethodparam)
{ entryTrace("myMethodName", myMethodParam);
}
exit trace is the opposite of that i.e. when the method is exited (only
when exited cleanly however, if there is an exception then you do not trace
this as an exit but put in exception tracing e.g.
myMethodName(char* mymethodparam)
{ entryTrace("myMethodName", myMethodParam);
{
// throwing an exception here
// no EXIT trace required but will trace the exception
traceException("exceptionID plus other useful information",
exception);
}
exitTrace("myMethodName", NULL);
return NULL;
}
Creation of entry and exit trace could be done using AspectC+
(http://www.aspectc.org). Then the code writer sees none of the entry and
exit trace thus saving code clutter. (There may be legal issues for us in
IBM using this so we are wary at the moment but urgently looking into it).
In terms of general trace - I would expect that to be whereever some useful
information is around and needs to be traced. Again ALL trace is switch
offable at the runtime if not required.
re: use of log4cpp. I think I don't care too much about either using this
system or adding in our own. With aspects you can simply create another
aspect that uses log4cpp instead of our own if that's peoples preference.
John Hawkins
Roshan
Weerasuriya
<roshan@opensourc To
e.lk> Apache AXIS C Developers List
<ax...@ws.apache.org>
06/08/2004 10:08 cc
Subject
Please respond to Re: Trace
"Apache AXIS C
Developers List"
hi John,
> How does the community feel about putting in entry and exit trace?
What do you mean by entry and exit trace? You mean the entry point and
the exit point of the problematic situation or something else?
>we can
> put it in as a build time option ie. write a program to put it in
> automatically when building. This is the least error prone way of doing
it.
Also what do you mean by "write a program to put it in automatically
when building" ?
In my openion, if the trace provides information to describe the
situation well, the community would be ok of it. The amount of stuff put
to the trace (certainly only the necessory once), doesn't cause any
issue, because it is just to describe the situation well. So if you need
those then I guess you could certainly put them. Adding them will not
cause any issues on performance etc, only a bunch of details will be
caused to print at exceptional situations. But if the trace is not only
used at exceptional situations, but also at normal situations may be
just to log details at runtime, then the amount put in the trace might
cause performance issues.
Roshan
On Fri, 2004-08-06 at 14:02, John Hawkins wrote:
>
>
> How does the community feel about putting in entry and exit trace?
> This is essential for the production level of code that we require. we
can
> put it in as a build time option ie. write a program to put it in
> automatically when building. This is the least error prone way of doing
it.
>
>
> John Hawkins
>
>
>
>
>
> damitha kumarage
> <damitha@opensour
> ce.lk>
To
> Apache AXIS C Developers List
> 06/08/2004 07:33 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
> Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
> and see
> whether we can plug it to Axis C++.
>
> Thanks
> damitha
>
> On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
> >
> >
> > +1 that was the solution we came up with a few minutes after me sending
> > this note :-)
> >
> >
> > John Hawkins
> > IBM,
> > AspectX Architect,
> > C web services client dev.
> >
> > +44 (0) 1962 817131
> >
> >
> >
> >
>
> > Samisa Abeysinghe
>
> > <samisa_abeysingh
>
> > e@yahoo.com>
> To
> > Apache AXIS C Developers List
>
> > 05/08/2004 11:53 <ax...@ws.apache.org>
>
> >
> cc
> >
>
> > Please respond to
> Subject
> > "Apache AXIS C Re: Trace
>
> > Developers List"
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Sounds good to me.
> >
> > As the method body of 'trace' is excuted only if the trace option is
set
> > this would not be a
> > problem for individual cases.
> > However, depending on how often the method is called, there could be a
> > performance hit. (but may
> > be this is negligible at times)
> >
> > To let those who wish to go without the trace at all, we could use both
> the
> > dynamic and static
> > options in combination. (i.e. have both compiler option and conf file
> > option)
> >
> > Thanks,
> > Samisa...
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> > http://promotions.yahoo.com/new_mail
> >
> >
> >
>
>
>
>
Re: Trace
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi Roshan,
Entry and exit trace:
This is where, at the start of every method - you put in trace to say that
you are entering that method with the parameters that are going into that
method e.g.
myMethodName(char* mymethodparam)
{ entryTrace("myMethodName", myMethodParam);
}
exit trace is the opposite of that i.e. when the method is exited (only
when exited cleanly however, if there is an exception then you do not trace
this as an exit but put in exception tracing e.g.
myMethodName(char* mymethodparam)
{ entryTrace("myMethodName", myMethodParam);
{
// throwing an exception here
// no EXIT trace required but will trace the exception
traceException("exceptionID plus other useful information",
exception);
}
exitTrace("myMethodName", NULL);
return NULL;
}
Creation of entry and exit trace could be done using AspectC+
(http://www.aspectc.org). Then the code writer sees none of the entry and
exit trace thus saving code clutter. (There may be legal issues for us in
IBM using this so we are wary at the moment but urgently looking into it).
In terms of general trace - I would expect that to be whereever some useful
information is around and needs to be traced. Again ALL trace is switch
offable at the runtime if not required.
re: use of log4cpp. I think I don't care too much about either using this
system or adding in our own. With aspects you can simply create another
aspect that uses log4cpp instead of our own if that's peoples preference.
John Hawkins
Roshan
Weerasuriya
<roshan@opensourc To
e.lk> Apache AXIS C Developers List
<ax...@ws.apache.org>
06/08/2004 10:08 cc
Subject
Please respond to Re: Trace
"Apache AXIS C
Developers List"
hi John,
> How does the community feel about putting in entry and exit trace?
What do you mean by entry and exit trace? You mean the entry point and
the exit point of the problematic situation or something else?
>we can
> put it in as a build time option ie. write a program to put it in
> automatically when building. This is the least error prone way of doing
it.
Also what do you mean by "write a program to put it in automatically
when building" ?
In my openion, if the trace provides information to describe the
situation well, the community would be ok of it. The amount of stuff put
to the trace (certainly only the necessory once), doesn't cause any
issue, because it is just to describe the situation well. So if you need
those then I guess you could certainly put them. Adding them will not
cause any issues on performance etc, only a bunch of details will be
caused to print at exceptional situations. But if the trace is not only
used at exceptional situations, but also at normal situations may be
just to log details at runtime, then the amount put in the trace might
cause performance issues.
Roshan
On Fri, 2004-08-06 at 14:02, John Hawkins wrote:
>
>
> How does the community feel about putting in entry and exit trace?
> This is essential for the production level of code that we require. we
can
> put it in as a build time option ie. write a program to put it in
> automatically when building. This is the least error prone way of doing
it.
>
>
> John Hawkins
>
>
>
>
>
> damitha kumarage
> <damitha@opensour
> ce.lk>
To
> Apache AXIS C Developers List
> 06/08/2004 07:33 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
> Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
> and see
> whether we can plug it to Axis C++.
>
> Thanks
> damitha
>
> On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
> >
> >
> > +1 that was the solution we came up with a few minutes after me sending
> > this note :-)
> >
> >
> > John Hawkins
> > IBM,
> > AspectX Architect,
> > C web services client dev.
> >
> > +44 (0) 1962 817131
> >
> >
> >
> >
>
> > Samisa Abeysinghe
>
> > <samisa_abeysingh
>
> > e@yahoo.com>
> To
> > Apache AXIS C Developers List
>
> > 05/08/2004 11:53 <ax...@ws.apache.org>
>
> >
> cc
> >
>
> > Please respond to
> Subject
> > "Apache AXIS C Re: Trace
>
> > Developers List"
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Sounds good to me.
> >
> > As the method body of 'trace' is excuted only if the trace option is
set
> > this would not be a
> > problem for individual cases.
> > However, depending on how often the method is called, there could be a
> > performance hit. (but may
> > be this is negligible at times)
> >
> > To let those who wish to go without the trace at all, we could use both
> the
> > dynamic and static
> > options in combination. (i.e. have both compiler option and conf file
> > option)
> >
> > Thanks,
> > Samisa...
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> > http://promotions.yahoo.com/new_mail
> >
> >
> >
>
>
>
>
Re: Trace
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
hi John,
> How does the community feel about putting in entry and exit trace?
What do you mean by entry and exit trace? You mean the entry point and
the exit point of the problematic situation or something else?
>we can
> put it in as a build time option ie. write a program to put it in
> automatically when building. This is the least error prone way of doing it.
Also what do you mean by "write a program to put it in automatically
when building" ?
In my openion, if the trace provides information to describe the
situation well, the community would be ok of it. The amount of stuff put
to the trace (certainly only the necessory once), doesn't cause any
issue, because it is just to describe the situation well. So if you need
those then I guess you could certainly put them. Adding them will not
cause any issues on performance etc, only a bunch of details will be
caused to print at exceptional situations. But if the trace is not only
used at exceptional situations, but also at normal situations may be
just to log details at runtime, then the amount put in the trace might
cause performance issues.
Roshan
On Fri, 2004-08-06 at 14:02, John Hawkins wrote:
>
>
> How does the community feel about putting in entry and exit trace?
> This is essential for the production level of code that we require. we can
> put it in as a build time option ie. write a program to put it in
> automatically when building. This is the least error prone way of doing it.
>
>
> John Hawkins
>
>
>
>
>
> damitha kumarage
> <damitha@opensour
> ce.lk> To
> Apache AXIS C Developers List
> 06/08/2004 07:33 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
> Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
> and see
> whether we can plug it to Axis C++.
>
> Thanks
> damitha
>
> On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
> >
> >
> > +1 that was the solution we came up with a few minutes after me sending
> > this note :-)
> >
> >
> > John Hawkins
> > IBM,
> > AspectX Architect,
> > C web services client dev.
> >
> > +44 (0) 1962 817131
> >
> >
> >
> >
>
> > Samisa Abeysinghe
>
> > <samisa_abeysingh
>
> > e@yahoo.com>
> To
> > Apache AXIS C Developers List
>
> > 05/08/2004 11:53 <ax...@ws.apache.org>
>
> >
> cc
> >
>
> > Please respond to
> Subject
> > "Apache AXIS C Re: Trace
>
> > Developers List"
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Sounds good to me.
> >
> > As the method body of 'trace' is excuted only if the trace option is set
> > this would not be a
> > problem for individual cases.
> > However, depending on how often the method is called, there could be a
> > performance hit. (but may
> > be this is negligible at times)
> >
> > To let those who wish to go without the trace at all, we could use both
> the
> > dynamic and static
> > options in combination. (i.e. have both compiler option and conf file
> > option)
> >
> > Thanks,
> > Samisa...
> >
> >
> > --- John Hawkins <HA...@uk.ibm.com> wrote:
> >
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> > http://promotions.yahoo.com/new_mail
> >
> >
> >
>
>
>
>
Re: Trace
Posted by John Hawkins <HA...@uk.ibm.com>.
How does the community feel about putting in entry and exit trace?
This is essential for the production level of code that we require. we can
put it in as a build time option ie. write a program to put it in
automatically when building. This is the least error prone way of doing it.
John Hawkins
damitha kumarage
<damitha@opensour
ce.lk> To
Apache AXIS C Developers List
06/08/2004 07:33 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Trace
Developers List"
Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
and see
whether we can plug it to Axis C++.
Thanks
damitha
On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
>
>
> +1 that was the solution we came up with a few minutes after me sending
> this note :-)
>
>
> John Hawkins
> IBM,
> AspectX Architect,
> C web services client dev.
>
> +44 (0) 1962 817131
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com>
To
> Apache AXIS C Developers List
> 05/08/2004 11:53 <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
> Sounds good to me.
>
> As the method body of 'trace' is excuted only if the trace option is set
> this would not be a
> problem for individual cases.
> However, depending on how often the method is called, there could be a
> performance hit. (but may
> be this is negligible at times)
>
> To let those who wish to go without the trace at all, we could use both
the
> dynamic and static
> options in combination. (i.e. have both compiler option and conf file
> option)
>
> Thanks,
> Samisa...
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > 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.
> >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
>
>
>
Re: Trace
Posted by damitha kumarage <da...@opensource.lk>.
Perhaps we need to have a look at a good logging tool for c++(Log4cpp)
and see
whether we can plug it to Axis C++.
Thanks
damitha
On Thu, 2004-08-05 at 17:15, John Hawkins wrote:
>
>
> +1 that was the solution we came up with a few minutes after me sending
> this note :-)
>
>
> John Hawkins
> IBM,
> AspectX Architect,
> C web services client dev.
>
> +44 (0) 1962 817131
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 05/08/2004 11:53 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Re: Trace
> Developers List"
>
>
>
>
>
>
>
>
>
> Sounds good to me.
>
> As the method body of 'trace' is excuted only if the trace option is set
> this would not be a
> problem for individual cases.
> However, depending on how often the method is called, there could be a
> performance hit. (but may
> be this is negligible at times)
>
> To let those who wish to go without the trace at all, we could use both the
> dynamic and static
> options in combination. (i.e. have both compiler option and conf file
> option)
>
> Thanks,
> Samisa...
>
>
> --- John Hawkins <HA...@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > 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.
> >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
>
>
>
Re: Trace
Posted by John Hawkins <HA...@uk.ibm.com>.
+1 that was the solution we came up with a few minutes after me sending
this note :-)
John Hawkins
IBM,
AspectX Architect,
C web services client dev.
+44 (0) 1962 817131
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
05/08/2004 11:53 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Trace
Developers List"
Sounds good to me.
As the method body of 'trace' is excuted only if the trace option is set
this would not be a
problem for individual cases.
However, depending on how often the method is called, there could be a
performance hit. (but may
be this is negligible at times)
To let those who wish to go without the trace at all, we could use both the
dynamic and static
options in combination. (i.e. have both compiler option and conf file
option)
Thanks,
Samisa...
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> 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.
>
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: Trace
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Sounds good to me.
As the method body of 'trace' is excuted only if the trace option is set this would not be a
problem for individual cases.
However, depending on how often the method is called, there could be a performance hit. (but may
be this is negligible at times)
To let those who wish to go without the trace at all, we could use both the dynamic and static
options in combination. (i.e. have both compiler option and conf file option)
Thanks,
Samisa...
--- John Hawkins <HA...@uk.ibm.com> wrote:
>
>
>
>
> 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.
>
>
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail