You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Indrajit Raychaudhuri <ir...@indrajit.com> on 2003/10/11 09:44:24 UTC
Inconstency in declaring log instance
Hi,
What is the 'best practice' followed in declaring the class-wide log
instance in Struts?
LookupDispatchAction for example, doesn't have it declared explicitly since
DispatchAction has a protected instance which it can use (and subsequently a
subclass of LookupDispatchAction can use it as well).
OTOH, MappingDispatchAction (a sibling of LookupDispatchAction and having
similar functionality) has one declared explicitly and that is marked
private.
I was trying to figure out (and learn) the convention followed in declaring
the scope of log instances in a framework like Struts (private, protected)
and also, if protected, is there any design force that guides how they would
be used in the subclasses or is it going to be purely need driven.
Regards,
Indrajit
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Inconstency in declaring log instance
Posted by Indrajit Raychaudhuri <ir...@indrajit.com>.
Would certainly Bugzilla it :-)
- Indrajit
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Monday, 13 October, 2003 22:44
Subject: Re: Inconstency in declaring log instance
> Indrajit Raychaudhuri wrote:
>
> >Thanks very much for the suggestions, please see my comments marked
[IRC:]
> >
> >
> >----- Original Message -----
> >From: "Craig R. McClanahan" <cr...@apache.org>
> >To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> >Sent: Saturday, 11 October, 2003 22:48
> >Subject: Re: Inconstency in declaring log instance
> >
> >
> >| Indrajit Raychaudhuri wrote:
> >|
> >| >Hi,
> >| >
> >| >What is the 'best practice' followed in declaring the class-wide log
> >| >instance in Struts?
> >| >
> >| >LookupDispatchAction for example, doesn't have it declared explicitly
> >since
> >| >DispatchAction has a protected instance which it can use (and
> >subsequently a
> >| >subclass of LookupDispatchAction can use it as well).
> >| >OTOH, MappingDispatchAction (a sibling of LookupDispatchAction and
having
> >| >similar functionality) has one declared explicitly and that is marked
> >| >private.
> >| >
> >|
> >| ...
> >| ...
> >|
> >| The typical convention on Struts and Commons code is to use the fully
> >| qualified class name of the containing class to be the logger name
> >| (that's what happens when you pass a Class to the getLog() method, but
> >| you can also pass a String). This leverages the fact that most logging
> >| systems allow you to specify hierarchical control over the logging
> >| detail level by specifying just the early part of the name.
> >|
> >
> >[IRC:] Either way, since Commons and Struts are more of infrastructure
code,
> >we can have a bit more consistent convention.
> >Couple of options could be:
> >(a) have protected log instance for every non-final (subclassable) class
> >[e.g., DispatchAction, LookupDispatctAction etc.] in the hierarchy. So
that
> >a developer has the option of using parents log instance or have another
> >instance of his own when he subclasses from either of DA or LookupDA.
> >(b) have private log instance for the classes shipped with Struts and
> >Commons and enforce instantiation at the developers' subclass.
> >(c) any other convention Struts-dev group agrees upon :)
> >
> >These are just my observation - I could have overlooked something though.
> >
> >
>
> Option (d) - since this is open source :-), take the opportunity to try
> to become one of the struts-dev group, by submitting enhancement
> requests and bug reports, with suggested patches to fix the problem, to
> the bug tracking system:
>
> http://nagoya.apache.org/bugzilla/
>
> I don't have a problem with protected log instances for subclassable
> classes. If I were you, I'd certainly start with the specific classes
> you care the most about. Improved documentation is also appreciated.
>
> General suggestions and advice on how to contribute:
>
> http://jakarta.apache.org/site/getinvolved.html
>
> Craig
>
>
>
>
>
> >| Consider the following log detail levels, which might show up in a JDK
> >| 1.4 logging.properties file:
> >|
> >| # Establish overall level for all Commons packages
> >| org.apache.commons.level = SEVERE
> >|
> >| # Establish overall level for all Struts packages
> >| org.apache.struts.level = INFO
> >|
> >| # I want to trace the RequestProcessor to figure out a problem
> >| org.apache.struts.action.RequestProcessor.level = FINEST
> >|
> >| When a class inherits the logger from its base class, that means they
> >| are also sharing the same logger name (the one from the base class),
and
> >| you can't control the logging levels independently. But normally that
> >| is not a problem. (Note that the base class logger would need to be
> >| "protected" rather than "private" in order for it to be shared, just
> >| like any other base class variable.)
> >|
> >| Nothing at all *requires* you to use class names as logger names -- you
> >| can name the loggers whatever you want. Class names provide an easy
way
> >| to avoid name clashes, but they don't help you as much if you've got
> >| more than one user of the same class, and you'd like to log differently
> >| for them. Or, you might want to have two or more different loggers in
> >| the same class. Or, you might want to share the same logger between
all
> >| classes in a package. There's lots of options.
> >
> >[IRC:] Pretty much well understood. In fact, getLog(Calzz.class) in turn
> >would call LogFactoryImpl.getInstance(clazz.getName()) and subsequently,
> >this becomes the key in the HashTable of "instances". This is pretty
much
> >sufficient (and elegant) measure in avoiding name clashes and I don't
find
> >enough reason to try out differently. Of course, I might have to deviate
a
> >bit from the convention if I had to have (quite infrequently) multiple
> >logger per class or multiple class per logger. Or if I wanted to have a
> >different type granularity in logging.
> >
> >|
> >
> >| ...
> >| ...
> >|
> >|
> >| >Regards,
> >| >Indrajit
> >| >
> >| >
> >|
> >| Craig
> >|
> >
> > - Indrajit
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Inconstency in declaring log instance
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Indrajit Raychaudhuri wrote:
>Thanks very much for the suggestions, please see my comments marked [IRC:]
>
>
>----- Original Message -----
>From: "Craig R. McClanahan" <cr...@apache.org>
>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>Sent: Saturday, 11 October, 2003 22:48
>Subject: Re: Inconstency in declaring log instance
>
>
>| Indrajit Raychaudhuri wrote:
>|
>| >Hi,
>| >
>| >What is the 'best practice' followed in declaring the class-wide log
>| >instance in Struts?
>| >
>| >LookupDispatchAction for example, doesn't have it declared explicitly
>since
>| >DispatchAction has a protected instance which it can use (and
>subsequently a
>| >subclass of LookupDispatchAction can use it as well).
>| >OTOH, MappingDispatchAction (a sibling of LookupDispatchAction and having
>| >similar functionality) has one declared explicitly and that is marked
>| >private.
>| >
>|
>| ...
>| ...
>|
>| The typical convention on Struts and Commons code is to use the fully
>| qualified class name of the containing class to be the logger name
>| (that's what happens when you pass a Class to the getLog() method, but
>| you can also pass a String). This leverages the fact that most logging
>| systems allow you to specify hierarchical control over the logging
>| detail level by specifying just the early part of the name.
>|
>
>[IRC:] Either way, since Commons and Struts are more of infrastructure code,
>we can have a bit more consistent convention.
>Couple of options could be:
>(a) have protected log instance for every non-final (subclassable) class
>[e.g., DispatchAction, LookupDispatctAction etc.] in the hierarchy. So that
>a developer has the option of using parents log instance or have another
>instance of his own when he subclasses from either of DA or LookupDA.
>(b) have private log instance for the classes shipped with Struts and
>Commons and enforce instantiation at the developers' subclass.
>(c) any other convention Struts-dev group agrees upon :)
>
>These are just my observation - I could have overlooked something though.
>
>
Option (d) - since this is open source :-), take the opportunity to try
to become one of the struts-dev group, by submitting enhancement
requests and bug reports, with suggested patches to fix the problem, to
the bug tracking system:
http://nagoya.apache.org/bugzilla/
I don't have a problem with protected log instances for subclassable
classes. If I were you, I'd certainly start with the specific classes
you care the most about. Improved documentation is also appreciated.
General suggestions and advice on how to contribute:
http://jakarta.apache.org/site/getinvolved.html
Craig
>| Consider the following log detail levels, which might show up in a JDK
>| 1.4 logging.properties file:
>|
>| # Establish overall level for all Commons packages
>| org.apache.commons.level = SEVERE
>|
>| # Establish overall level for all Struts packages
>| org.apache.struts.level = INFO
>|
>| # I want to trace the RequestProcessor to figure out a problem
>| org.apache.struts.action.RequestProcessor.level = FINEST
>|
>| When a class inherits the logger from its base class, that means they
>| are also sharing the same logger name (the one from the base class), and
>| you can't control the logging levels independently. But normally that
>| is not a problem. (Note that the base class logger would need to be
>| "protected" rather than "private" in order for it to be shared, just
>| like any other base class variable.)
>|
>| Nothing at all *requires* you to use class names as logger names -- you
>| can name the loggers whatever you want. Class names provide an easy way
>| to avoid name clashes, but they don't help you as much if you've got
>| more than one user of the same class, and you'd like to log differently
>| for them. Or, you might want to have two or more different loggers in
>| the same class. Or, you might want to share the same logger between all
>| classes in a package. There's lots of options.
>
>[IRC:] Pretty much well understood. In fact, getLog(Calzz.class) in turn
>would call LogFactoryImpl.getInstance(clazz.getName()) and subsequently,
>this becomes the key in the HashTable of "instances". This is pretty much
>sufficient (and elegant) measure in avoiding name clashes and I don't find
>enough reason to try out differently. Of course, I might have to deviate a
>bit from the convention if I had to have (quite infrequently) multiple
>logger per class or multiple class per logger. Or if I wanted to have a
>different type granularity in logging.
>
>|
>
>| ...
>| ...
>|
>|
>| >Regards,
>| >Indrajit
>| >
>| >
>|
>| Craig
>|
>
> - Indrajit
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Inconstency in declaring log instance
Posted by Indrajit Raychaudhuri <ir...@indrajit.com>.
Thanks very much for the suggestions, please see my comments marked [IRC:]
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Saturday, 11 October, 2003 22:48
Subject: Re: Inconstency in declaring log instance
| Indrajit Raychaudhuri wrote:
|
| >Hi,
| >
| >What is the 'best practice' followed in declaring the class-wide log
| >instance in Struts?
| >
| >LookupDispatchAction for example, doesn't have it declared explicitly
since
| >DispatchAction has a protected instance which it can use (and
subsequently a
| >subclass of LookupDispatchAction can use it as well).
| >OTOH, MappingDispatchAction (a sibling of LookupDispatchAction and having
| >similar functionality) has one declared explicitly and that is marked
| >private.
| >
|
| ...
| ...
|
| The typical convention on Struts and Commons code is to use the fully
| qualified class name of the containing class to be the logger name
| (that's what happens when you pass a Class to the getLog() method, but
| you can also pass a String). This leverages the fact that most logging
| systems allow you to specify hierarchical control over the logging
| detail level by specifying just the early part of the name.
|
[IRC:] Either way, since Commons and Struts are more of infrastructure code,
we can have a bit more consistent convention.
Couple of options could be:
(a) have protected log instance for every non-final (subclassable) class
[e.g., DispatchAction, LookupDispatctAction etc.] in the hierarchy. So that
a developer has the option of using parents log instance or have another
instance of his own when he subclasses from either of DA or LookupDA.
(b) have private log instance for the classes shipped with Struts and
Commons and enforce instantiation at the developers' subclass.
(c) any other convention Struts-dev group agrees upon :)
These are just my observation - I could have overlooked something though.
| Consider the following log detail levels, which might show up in a JDK
| 1.4 logging.properties file:
|
| # Establish overall level for all Commons packages
| org.apache.commons.level = SEVERE
|
| # Establish overall level for all Struts packages
| org.apache.struts.level = INFO
|
| # I want to trace the RequestProcessor to figure out a problem
| org.apache.struts.action.RequestProcessor.level = FINEST
|
| When a class inherits the logger from its base class, that means they
| are also sharing the same logger name (the one from the base class), and
| you can't control the logging levels independently. But normally that
| is not a problem. (Note that the base class logger would need to be
| "protected" rather than "private" in order for it to be shared, just
| like any other base class variable.)
|
| Nothing at all *requires* you to use class names as logger names -- you
| can name the loggers whatever you want. Class names provide an easy way
| to avoid name clashes, but they don't help you as much if you've got
| more than one user of the same class, and you'd like to log differently
| for them. Or, you might want to have two or more different loggers in
| the same class. Or, you might want to share the same logger between all
| classes in a package. There's lots of options.
[IRC:] Pretty much well understood. In fact, getLog(Calzz.class) in turn
would call LogFactoryImpl.getInstance(clazz.getName()) and subsequently,
this becomes the key in the HashTable of "instances". This is pretty much
sufficient (and elegant) measure in avoiding name clashes and I don't find
enough reason to try out differently. Of course, I might have to deviate a
bit from the convention if I had to have (quite infrequently) multiple
logger per class or multiple class per logger. Or if I wanted to have a
different type granularity in logging.
|
| ...
| ...
|
|
| >Regards,
| >Indrajit
| >
| >
|
| Craig
|
- Indrajit
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Inconstency in declaring log instance
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Indrajit Raychaudhuri wrote:
>Hi,
>
>What is the 'best practice' followed in declaring the class-wide log
>instance in Struts?
>
>LookupDispatchAction for example, doesn't have it declared explicitly since
>DispatchAction has a protected instance which it can use (and subsequently a
>subclass of LookupDispatchAction can use it as well).
>OTOH, MappingDispatchAction (a sibling of LookupDispatchAction and having
>similar functionality) has one declared explicitly and that is marked
>private.
>
>I was trying to figure out (and learn) the convention followed in declaring
>the scope of log instances in a framework like Struts (private, protected)
>and also, if protected, is there any design force that guides how they would
>be used in the subclasses or is it going to be purely need driven.
>
>
Best practice really depends on how fine-grained you want your logger
names to be, so that you can individually manage the level of detail to
be produced for that logger (which is controlled by the logger name).
The typical convention on Struts and Commons code is to use the fully
qualified class name of the containing class to be the logger name
(that's what happens when you pass a Class to the getLog() method, but
you can also pass a String). This leverages the fact that most logging
systems allow you to specify hierarchical control over the logging
detail level by specifying just the early part of the name.
Consider the following log detail levels, which might show up in a JDK
1.4 logging.properties file:
# Establish overall level for all Commons packages
org.apache.commons.level = SEVERE
# Establish overall level for all Struts packages
org.apache.struts.level = INFO
# I want to trace the RequestProcessor to figure out a problem
org.apache.struts.action.RequestProcessor.level = FINEST
When a class inherits the logger from its base class, that means they
are also sharing the same logger name (the one from the base class), and
you can't control the logging levels independently. But normally that
is not a problem. (Note that the base class logger would need to be
"protected" rather than "private" in order for it to be shared, just
like any other base class variable.)
Nothing at all *requires* you to use class names as logger names -- you
can name the loggers whatever you want. Class names provide an easy way
to avoid name clashes, but they don't help you as much if you've got
more than one user of the same class, and you'd like to log differently
for them. Or, you might want to have two or more different loggers in
the same class. Or, you might want to share the same logger between all
classes in a package. There's lots of options.
I'd suggest starting with the logger-per-class paradigm and become
familiar with tuning the logging of the classes individually. Then, you
can look at tweaking things for particular needs. One note, however; if
you decide to use a different convention (either locally to a few
classes, or globally in your app), you should note the logger names
you're using in the class Javadocs, so people using your classes know
what logger names they can configure.
>Regards,
>Indrajit
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org