Logging in ATG

[Subodh]

Hi All,

I am new to ATG. Currently we are working on a project where we need
to design the logging framework. May I know if we should use the
existing ATG apis or log4j and what are pros and cons of each? Also
let me know some links where I can find some useful information around
this.

Regards.

[Raja Ramachandran]

I prefer the ATG logging framework as you can really control the logging at each component level and it can be turned on/off at runtime. If you chose  to use the ATG's logging framework,  extend the ApplicationLoggingImpl class and provide a version of log*** methods that checks for the isLoggingDebug flag internally. That would prevent the cluttering of code with" if ( isLoggingDebug() )" checks.

[Wilco Boumans]

Although extending the methods avoids cluttering the code, it also comes with a side-effect:

The string you pass into the log* method is evaluated, even if your debug level is higher and nothing is logged.

This normally doesn't hurt that much, but sometimes a huge String is calculated and passed in as a param.

For another opinion on ATG logging see

http://blog.pulleman.com/2007/11/04/do-not-use-the-atg-applicationlogging-api/

Cheers,

Wilco

[John Cooke]

The points made in the blog are good points.  As with anything in software it really depends on what you are doing.  Using technology for technologies sake does not always make sense.  log4j and ATG Logging both have their time and place.

Using the ATG logging API you can make calls to resolve the actual instance of the component you are referencing. 

if(isLoggingDebug()) {

  logDebug(getAbsoluteName() + "Somemethod()........);

}

Which will tell you not only the class but the specific instance.  I do not have a lot of experience with log4j but I have found the ATG Logging APIs very usable and fast.  I am sure that you can stitch the two together and end up with a extremely flexible logging framework.  I do know companies that have wrapped the log4j calls in the ATG application logging framework and the other way around.

If your entire application is ATG based I do not see a benefit in adding in the log4j framework as the core ATG product stack will still be using application logging and you will then need to keep track of which class is using which logging framework in order to enable/disable various logging levels.  In some cases you will end up with components that use both (Out-of-the box parent classes and you custom extensions) and you will need to modify both the log4j configs and the ATG configs to pull all of the relevant debugging.

my 2 cents,

Gordon Cooke

Spark::red - Managed ATG Hosting

http://www.sparkred.com

[Devon]

I'm going to disagree with a few points in the blog actually.

Being able to change the logging level, live, of a single component,
on a single instance is a far more useful tool for tracking down
issues, espeically in production, than activating an entire category
in log4j. It can also be done via the web admin in a non-persistent
manner, without editing deployed files. This makes it much less
likely to accidentally leave logging on, or break the config file with
a typo.

As Gordon pointed out, by wrapping your logging calls in the if block
you avoid the overhead of String creation and concatenation. (Seam
actually solves the concatenation problem nicely using EL
expressions.) A simple eclipse template makes generated logging
blocks the work of two key presses.

Don't get me wrong, log4j is a good logging system. But if you're
developing an ATG application, the ATG logging framework is the best
approach in my opinion. Especially since all the ATG code itself is
using it, so your logs will be formatted in a similar fashion. I have
written bridges to allow one system to talk to the other, so if you
need to you can do that, but don't dismiss ATG logging because of that
blog entry.

On Jan 17, 10:53 am, Wilco Boumans <wilco.boum...@gmail.com> wrote:
> Although extending the methods avoids cluttering the code, it also  
> comes with a side-effect:
> The string you pass into the log* method is evaluated, even if your  
> debug level is higher and nothing is logged.
>
> This normally doesn't hurt that much, but sometimes a huge String is  
> calculated and passed in as a param.
>

> For another opinion on ATG logging seehttp://blog.pulleman.com/2007/11/04/do-not-use-the-atg-applicationlog...

>
> Cheers,
> Wilco
>
> On 17 Jan, 2008, at 19:27 PM, Raja Ramachandran wrote:
>
> > I prefer the ATG logging framework as you can really control the  
> > logging at each component level and it can be turned on/off at  
> > runtime. If you chose  to use the ATG's logging framework,  extend  
> > the ApplicationLoggingImpl class and provide a version of log***  
> > methods that checks for the isLoggingDebug flag internally. That  
> > would prevent the cluttering of code with" if ( isLoggingDebug() )"  
> > checks.
>

[RoBot]

Wilco is absolutely right. What Raja suggests is really a bad bad
practice. If you are going that route than the isLoggingdebug()
method is completely pointless. Do you understand why that method
exists?

But rest assured. You are not the only doing that...

On Jan 17, 7:53 pm, Wilco Boumans <wilco.boum...@gmail.com> wrote:
> Although extending the methods avoids cluttering the code, it also
> comes with a side-effect:
> The string you pass into the log* method is evaluated, even if your
> debug level is higher and nothing is logged.
>
> This normally doesn't hurt that much, but sometimes a huge String is
> calculated and passed in as a param.
>

> For another opinion on ATG logging seehttp://blog.pulleman.com/2007/11/04/do-not-use-the-atg-applicationlog...

>
> Cheers,
> Wilco
>
> On 17 Jan, 2008, at 19:27 PM, Raja Ramachandran wrote:
>
> > I prefer the ATG logging framework as you can really control the
> > logging at each component level and it can be turned on/off at
> > runtime. If you chose to use the ATG's logging framework, extend
> > the ApplicationLoggingImpl class and provide a version of log***
> > methods that checks for the isLoggingDebug flag internally. That
> > would prevent the cluttering of code with" if ( isLoggingDebug() )"
> > checks.
>

[RoBot]

Good points John.

Still when using JBoss (the point of my Blog) you will have Log4J as
JBoss default. So we will not add Log4j, we already have it.
Stronger even. Have you noticed the ATG logging goes through JBoss and
suddenly it is ATG logging wrapped in Log4J.

However perhaps there is a way to circumvent that. I have not found
one yet.

> Spark::red - Managed ATG Hostinghttp://www.sparkred.com

>
> On Jan 17, 2008, at 10:53 AM, Wilco Boumans wrote:
>
>
>
> > Although extending the methods avoids cluttering the code, it also
> > comes with a side-effect:
> > The string you pass into the log* method is evaluated, even if your
> > debug level is higher and nothing is logged.
>
> > This normally doesn't hurt that much, but sometimes a huge String is
> > calculated and passed in as a param.
>
> > For another opinion on ATG logging see

> >http://blog.pulleman.com/2007/11/04/do-not-use-the-atg-applicationlog...

>
> > Cheers,
> > Wilco
>
> > On 17 Jan, 2008, at 19:27 PM, Raja Ramachandran wrote:
>
> >> I prefer the ATG logging framework as you can really control the
> >> logging at each component level and it can be turned on/off at
> >> runtime. If you chose to use the ATG's logging framework, extend
> >> the ApplicationLoggingImpl class and provide a version of log***
> >> methods that checks for the isLoggingDebug flag internally. That
> >> would prevent the cluttering of code with" if ( isLoggingDebug() )"
> >> checks.
>

[RoBot]

> I'm going to disagree with a few points in the blog actually.
>
> Being able to change the logging level, live, of a single component,
> on a single instance is a far more useful tool for tracking down
> issues, espeically in production, than activating an entire category
> in log4j. It can also be done via the web admin in a non-persistent
> manner, without editing deployed files. This makes it much less
> likely to accidentally leave logging on, or break the config file with
> a typo.

Very good points! This is a case where I'm not sure how to solve that
with only Log4J.

Just curious did you ever encounter the need to change the logging of
a single instance in a life system?

And yes never dismiss something on one Blog entry ;-)

[raja...@gmail.com]

Not necessarily. If you externalize your constant strings, use stringbuffer to construct the dynamic part and run your app on production grade machines, there is hardly any performance hit. A little readability of the code helps. There are purists and then there are pragmatists. Anyways I guess there are more votes for you on going the ATG way of logging. Implementing it in any which way is your call.
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: RoBot <pull...@gmail.com>

Date: Thu, 17 Jan 2008 15:38:29
To:ATG_Tech <atg_...@googlegroups.com>
Subject: [atg_tech:495] Re: Logging in ATG

[RoBot]

I'm not sure what you are saying and you may do whatever you want in
your project. :-)
I just don't think it is good advice to Subodh and I mean the part
about extending the ApplicationLoggingImpl class, not the preference
for ATG logging.

It is not clear to me if you consider yourself a purist or pragmatist.
Externalizing your constant strings (the ones you are using for
logging you mean?). Wow! and using StringBuffer (you are not on Java 5
yet I guess).

But as you said it is your call.

[John Cooke]

To answer the original question....
the difference between

if(isLoggingDebug()) {
logDebug("some string");
)

and

myclasslogDebug("some string");

with a method:
myclasslogDebug(String foo) {
if(isLoggingDebug() ) {
logDebug(foo);
}
}
is that in the first case the VM does not have to create the string
"some string", in the second case it does.

When I code I try not to instantiate something that is not needed.
This is why the ATG framework is the way that it is. if you have to
pass the string in, your performance will degrade as you put more and
more debug statements in. A simple boolean check against the method
call "isLoggingDebug()" is pretty painless and has a trivial impact on
performance. The first time I touched ATG on v4.x (yes a long time
ago) I was not aware of the boolean check. When we realized that
design of the boolean check and added it into all of our logging
statements the performance of the site close to doubled. Granted this
was a while ago and major improvements have been made in string
handling in the JVM but still....

It is up to you how you go about this. There is a valid argument for
readability of code. I personally do not thing it outweighs the
argument for degraded performance.

Gordon Cooke
Spark:red - Managed ATG Hosting

[RoBot]

Precisely Gordon that is my point. I agree. And to put it even more
strongly.
<quote>
And if you are going to write

myclasslogDebug("some string");

with a method:
myclasslogDebug(String foo) {
if(isLoggingDebug() ) {
logDebug(foo);
}

</quote>

there is no point to do that. You can replace that with logDebug(foo);
You have defeated the purpose of isLoggingDebug(). You don't have to
create a method for that. Just skip the isLogggingDebug(). The result
is pretty much the same
So if you go for the readability route just skip the isLoggingDebug(),
but don't wrap it.

And now I will stop :-)

[Subodh]

All,

Many thanks for your valuable inputs and we have decided to use ATG
logging in our project.

What I have read in ATG is that we have all logs in their respective
files i.e. debug logs in debug.log and error logs in error.log etc.
Can we have separate log file names (which I guess is yes), and can we
have separate logs based on functionality basis (e.g. separate log
file for say registration functionality having all info, debug,
warning and error logs with in that)? Does ATG provide this
flexibility and if yes how can we achieve this?

Thanks in advance.

[Gordon Cooke]

The logging facilities and the process by which you implement it is
detailed in the ATG docs. You can create as many custom loggers and
log event types as you want. Typically the overhead of creating
custom loggers for specific types of events outweighs the benefits.
You can achieve the same results by only turning debugging on on the
components you are trying to troubleshoot.
docs for logging are here:
https://www.atg.com/repositories/ContentCatalogRepository_en/manuals/ATG2006.3/dynprog/dynprog0601.html

Gordon Cooke
Spark::red - Managed ATG Hosting

http://sparkred.com