You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by ni...@apache.org on 2004/03/14 17:10:37 UTC
cvs commit: avalon-site/xdocs/developing strategies.xml
niclas 2004/03/14 08:10:37
Modified: xdocs/developing strategies.xml
Log:
Developing With Avalon saga continues...
Revision Changes Path
1.2 +192 -116 avalon-site/xdocs/developing/strategies.xml
Index: strategies.xml
===================================================================
RCS file: /home/cvs/avalon-site/xdocs/developing/strategies.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- strategies.xml 2 Nov 2003 11:10:48 -0000 1.1
+++ strategies.xml 14 Mar 2004 16:10:37 -0000 1.2
@@ -4,137 +4,213 @@
<properties>
<author email="hammant@apache.org">Paul Hammant</author>
<author email="bloritsch@apache.org">Berin Loritsch</author>
+ <author email="niclas@apache.org">Niclas Hedhman</author>
<title>It's a Stragedy!</title>
</properties>
-<body>
- <section name="It's a Stragedy!">
- <p>No, it's not a typo. The title has a deliberate play on words
- that implies that incorrect strategies can end up in tragedy. While
- the word "tragedy" may be a bit strong, the thought process does
- have a ring of truth to it. In this chapter we attempt to give you
- helpful hints and tips to boost the performance of your code and
- your development team. We will break the discussion into logging
- strategies, development strategies, component strategies, testing
- strategies, and finally some notes on security strategies.</p>
- </section>
- <section name="Logging Strategies">
-
- <p>Logging is a necessary function in any system. The problem
- arises when the logging is not implemented in an efficient
- manner. Before we get into the nuts and bolts of <em>how</em>
- to create an efficient logging implementation, we have to identify
- <em>what</em>
- logging efficiency is.</p>
-
- <p>In the spirit of the Separation of Concerns pattern, there
- are two problem domains to consider: log organization and log
- writing. Log organization is primarily concerned with how the
- log categories are organized, and how the log files are
- organized. Log writing has to do with the mechanics of writing
- log entries.</p>
+ <body>
+ <section name="It's a Stragedy!">
+ <p>
+ No, it's not a typo. The title has a deliberate play on words
+ that implies that incorrect strategies can end up in tragedy. While
+ the word "tragedy" may be a bit strong, the thought process does
+ have a ring of truth to it. In this chapter we attempt to give you
+ helpful hints and tips to boost the performance of your code and
+ your development team. We will break the discussion into logging
+ strategies, development strategies, component strategies and testing
+ strategies.
+ </p>
+ </section>
+ <section name="Logging Strategies">
+ <p>
+ Logging is a necessary function in any system. The problem
+ arises when the logging is not implemented in an efficient
+ manner. Before we get into the nuts and bolts of <em>how</em>
+ to create an efficient logging implementation, we have to identify
+ <em>what</em> logging efficiency is.
+ </p>
+ <p>
+ In the spirit of the Separation of Concerns pattern, there
+ are two problem domains to consider: log organization and log
+ writing. Log organization is primarily concerned with how the
+ log categories are organized, and how the log files are
+ organized. Log writing has to do with the mechanics of writing
+ log entries. Log writing is in turn split into at least two
+ concerns, the output target and the formatting.
+ </p>
<subsection name="Log Organization">
-
- <p>The Avalon framework and team advocate a category based
- approach to organizing loggers as opposed to a class name
- based approach. There is a very good reason for this. First
- is that categorization allows you to put information of like
- kind in one location. Second, it allows you to turn on and
- off an entire category of log messages.</p>
-
- <p>The arguments for the class name based logging usually
- fall under these assumptions:</p>
-
- <ol>
- <li>
- <p>There is an implicit match between a class and a category.</p>
- </li>
-
- <li>
- <p>It makes it easier to get debug information from a
- specific class if we are having problems with it.</p>
- </li>
-
- <li>
- <p>The configuration file can handle the actual mapping
- of classname to log file.</p> </li>
+ <p>
+ The Avalon Framework and team advocate a category based
+ approach to organizing loggers as opposed to a class name
+ based approach. There is a very good reason for this. First
+ is that categorization allows you to put information of like
+ kind in one location. Second, it allows you to turn on and
+ off an entire category of log messages.
+ </p>
+
+ <p>
+ The arguments for the class name based logging usually
+ fall under these assumptions:
+ </p>
+ <ol>
+ <li>
+ There is an implicit match between a class and a category.
+ </li>
+ <li>
+ It makes it easier to get debug information from a
+ specific class if we are having problems with it.
+ </li>
+
+ <li>
+ The configuration file can handle the actual mapping
+ of classname to log file.
+ </li>
</ol>
- <p>While these arguments have their point, so does a strict
- category based logging approach:</p>
-
- <ol>
- <li>
- <p>You can narrow your log messages farther than simple
+ <p>
+ While these arguments have their point, so does a strict
+ category based logging approach:
+ </p>
+
+ <ol>
+ <li>
+ You can narrow your log messages farther than simple
class granularity. This way you can get information from
- the part of the class that really needs it.</p> </li>
+ the part of the class that really needs it.
+ </li>
- <li>
- <p>More often than not, a group of classes make up a
- Component. In most cases, the Component is what you are
- really interested in--not the individual classes.</p>
- </li>
-
- <li>
- <p>It is easier to manage a configuration file with
- only a few categories that are bound to Component
+ <li>
+ More often than not, a group of classes make up a
+ component. In most cases, the component is what you are
+ really interested in--not the individual classes.
+ </li>
+
+ <li>
+ It is easier to manage a configuration file with
+ only a few categories that are bound to component
instances during runtime you can separate the log files by
- who is concerned with their contents.</p> </li>
- </ol>
+ who is concerned with their contents.
+ </li>
+ </ol>
+ <p>
+ The issue is made more complex by the fact that Log4J has
+ a dot-notation hierarchical category system, but is most
+ often used for the package/class hierarchy, and not by
+ explicit names.
+ </p>
+ <p>
+ Avalon Logging is an interesting approach, where the component
+ declares the Loggers it want to have available in the Type
+ descriptor, and the container satisfy this need, by mapping
+ those categories to the underlying logging system's categories.
+ Furthermore, you set the priority for each such category in
+ the block.xml, which can be overridden in the config.xml.
+ </p>
</subsection>
<subsection name="Log Category Organization">
-
- <p>I would argue that it is a mistake to use only one
- category for all logging. The reason is that you will
- inevitably need to turn on and off a whole class of
- messages. Another reason is that you will need at least one
- category for each log file you have. One effective approach
- is to separate your logging needs into roles and
- classifications.</p>
-
- <p>If you have already decomposed your system into
- Components, then you have one set of categories defined. I
- would use a shorthand name for the category names for simple
- reference (e.g. "resource" instead of
- "org.apache.avalon.excalibur.resource.ResourceManager"). The
- simplified names can be used for a broad set of
- classes. Using the same example, the name "resource" implies
- the Resource class, its manager, and anything that is
- directly associated with the concept of a "resource".</p>
-
- <p>You can also use classifications as a specialization of
- the main role classification. For example, all
- ComponentManager code would have a category name of
- "component". This would allow you to have a Category manager
- for the aforementioned "resource" infrastructure. Typically
- classifications are sub-categories. In this case, the full
- name of the "component" category would be
- "resource.component". This means that we are referring to the
- "component" classification for the "resource" role.</p>
-
- <p>Most of your logging needs can be organized into this two
- dimensional cross-section of Role and Classification. Roles are
- best for main categories due to their logical
- separation. Typical classifications are "component", "security",
- and "pool". These same classifications can be used as standard
- sub-categories of the different roles. This way your log entries
- can have fine-grained control that is logically organized.</p>
+ <p>
+ We argue that it is a mistake to use only one
+ category for all logging. The reason is that you will
+ inevitably need to turn on and off a whole class of
+ messages. Another reason is that you will need at least one
+ category for each log file you have. One effective approach
+ is to separate your logging needs into roles and
+ classifications. For instance, a network connection component
+ may have logging roles of "connections", "traffic" and "client".
+ </p>
+
+ <p>
+ If you have already decomposed your system into
+ components, then you have one set of categories defined. I
+ would use a shorthand name for the category names for simple
+ reference (e.g. "resource" instead of
+ "org.apache.avalon.excalibur.resource.ResourceManager"). The
+ simplified names can be used for a broad set of
+ classes. Using the same example, the name "resource" implies
+ the Resource class, its manager, and anything that is
+ directly associated with the concept of a "resource".
+ </p>
+
+ <p>
+ You can also use classifications as a specialization of
+ the role. Typically
+ classifications are sub-categories. For instance, the full
+ name of the "component" category would be
+ "resource.component". This means that we are referring to the
+ "component" classification for the "resource" role.
+ </p>
+
+ <p>
+ Most of your logging needs can be organized into this two
+ dimensional cross-section of Role and Classification. Roles are
+ best for main categories due to their logical
+ separation. Typical classifications are "component", "security",
+ and "pool". These same classifications can be used as standard
+ sub-categories of the different roles. This way your log entries
+ can have fine-grained control that is logically organized.
+ </p>
</subsection>
<subsection name="Log Writing">
- <p>
-The mechanics of log writing can vastly affect the
-performance of your code. For instance, if you concatenate several
-strings together in your log messages, the Java Virtual Machine
-converts the concatenation to a StringBuffer, and performs the
-expensive <code>toString</code> operation on the result. The
-<code>Logger</code> interface provides a mechanism to optimize away
-these conversions when they are not needed.</p>
-
- </subsection>
- </section>
+ <p>
+ The mechanics of log writing can vastly affect the
+ performance of your code. For instance, if you concatenate several
+ strings together in your log messages, the Java Virtual Machine
+ converts the concatenation to a StringBuffer, and performs the
+ expensive <code>toString</code> operation on the result. The
+ <code>Logger</code> interface provides a mechanism to optimize away
+ these conversions when they are not needed. It is fairly important
+ for performance reasons to have all your code following the following
+ pattern;
+ </p>
+<source>
+ if( logger.isDebugEnabled() )
+ logger.debug( "Some debug message..." );
+ :
+ :
+ if( logger.isInfoEnabled() )
+ logger.info( "some complex info message" );
+ :
+ :
+ if( logger.isWarnEnabled() )
+ logger.warn( "WARNING! " );
+ :
+ :
+ if( logger.isErrorEnabled() )
+ logger.error( "We had some problems..." );
+</source>
+ <p>
+ Finally, each logging system supports different types of log output
+ destinations and formatting. It is important to study the performance
+ impact on each of these features. For instance, Log4J can provide
+ source file and line number of where the log message was called from,
+ which is VERY expensive call, although very convenient in debugging
+ environments, it must be taken out during production. Another example
+ is to investigate the possible speed improvements of using
+ asynchronous targets and buffered streams.
+ </p>
+ <p>
+ <em>It is not uncommon for many applications that unchecked logging
+ result in negative speed impacts of a magnitude or more.</em>
+ </p>
+ </subsection>
+ </section>
+ <section name="Development Strategies">
+ <p>
+ <em>Work in progress.</em>
+ </p>
+ </section>
+ <section name="Component Strategies">
+ <p>
+ <em>Work in progress.</em>
+ </p>
+ </section>
+ <section name="Testing Strategies">
+ <p>
+ <em>Work in progress.</em>
+ </p>
+ </section>
</body>
</document>
-
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org