src/xdocs/plan.xml - logging-log4j1 - Git at Google

 <?xml version="1.0"?>
 <document>

   <properties>
     <author email="ceki@apache.org">Ceki Gulcu</author>
     <title>Release plan for log4j 1.3</title>
   </properties>

   <body>

     <section name="Plan? What plan?">

       <p>The following paragragh was adapted from the <a
       href="http://jakarta.apache.org/cactus/">Cactus</a> project's
       roadmap with the author's permission.
       </p>

       <p>Our users keep inventing better ways and adding new
 	requirements. The downside is that our todo list keeps
 	growing. The upside is that there is plenty of work to go
 	around. If you are interested in participating, send an email
 	on the log4j-dev@ mailing list stating your interest. You'll
 	be promptly enrolled. We're always looking for help!  Don't be
 	put off if in the "Volunteer" column already has a person
 	listed. Programming is fun, especially if it is done in a
 	team.
       </p>

       <p>

       </p>


     </section>

     <section name="Workplan for log4j 1.3">

       <p>The workplan for log4j 1.3 is not final. It is included here
 	to give you an idea of the future. The items are not listed in
 	any particular order.  As always, there is no scheduled
 	release date. The lack of schedule suprises and disturbs some
 	people. Writing good software, like good cooking, takes
 	time. If we make you wait, it is to create a better and more
 	reliable product.
       </p>

       <table class="ls" cellpadding="3" cellspacing="2">

 	<tr>
 	  <th>Label</th>
 	  <th>Comment</th>
 	  <th>Volunteer</th>
 	  <th>Status</th>
 	</tr>

 	<tr bgcolor="DDDDDD">
 	  <td><b>test cases</b></td>

 	  <td>
 	    <p>Writing test cases is not the most sexy part of
 	      software development but it is one of the most
 	      important.  Automated test cases allow us to catch bugs
 	      as early is possible.  It is strongly recommended to add
 	      a new test case with each new feature or component.</p>

 	    <p>Existing <em>Perl</em> language based test cases have been
 			migrated to junit (all-Java)based test
 	      cases.  The new tests are placed under the
 	      <code>tests/</code> directory.  It should be thus
 	      possible for participants in the project to understand
 	      the stucture of our tests and add tests for their
 	      components.
 	    </p>
 	  </td>

 	  <td>All committers</td>
 	  <td>ongoing effort</td>
 	</tr>

 	<tr>
 	  <td>Extensible XML configuration files</td>

 	  <td>
 	     <p>The DOMConfigurator is complex and not very
 	      flexible. It can only deal with elements that the
 	      developer knew about at compilation time. This has been
 	      an important drawback in the design of several appenders
 	      such as the the SMTPAppender and the
 	      RollingFileAppenders and its variants.  These appenders
 	      need to delegate certain task to sub-components which
 	      are configured separately.
 	    </p>

 	    <p>The new JoranConfigurator being created by Ceki will be based on
 	    a new 'module' know as Joran, which can convert XML files into other objects based
 	    on rules.  You can read more abouth Joran <b><u><a href="http://www.qos.ch/logging/JoranConfigurator.html">here</a></u></b>
 	    </p>
 	  </td>
 	  <td>Ceki</td>
 	  <td>Significantly progressed</td>
 	</tr>

 	<tr>
 	  <td>Log4j Domains</td>

 	  <td>
 	    <p>This is a very powerful and innovative concept that
 	    extends the notion of hierarchical loggers. It will also
 	    allow dynamic logging with pin-point accuracy. It was
 	    first suggested to me by Scott Stark of <a
 	    href="http://www.jboss.org">JBoss</a> fame.
 	    </p>
 	  </td>
 	  <td>Ceki</td>
 	  <td>design board</td>
 	</tr>

 	<tr>
 	  <td>Multiple implementations of Logger</td>

 	  <td>
 	    <p>Based on <code>RepositorySelectors</code> introduced in
 	      log4j 1.2, the user will be able to replace the
 	      <code>Logger</code> implementation. Several
 	      implementations will be provided offering different
 	      properties and functionality although none of the
 	      implementations will add new public methods.
 	    </p>
 	  </td>


 	  <td>?</td>
 	  <td>vaporware</td>
 	</tr>
 	<tr>
 	  <td>Plugins/Receivers</td>

 	  <td>
 	    <p>A Plugin framework has been designed and implemented.</p>
 	    <p>All of the currently developed plugins are "Receivers", which can be thought of as the reverse of an appender; something
 	    that <b>accepts</b> LoggingEvents from some external source.
 	    </p>
 	    <p>This has proven particulaly useful with the log4j ports, with the addition of the XML-based Receivers able to accept
 	    LoggingEvents generated from other languages (see "Overture to other programming languages" below)
 	    </p>

 	  </td>
 	  <td>All</td>
 	  <td>Significantly progressed</td>
 	</tr>

 	<tr>
 	  <td>Improvements to Chainsaw</td>

 	  <td>
 	    <p><a href="chainsaw.html">Chainsaw v2</a> development has now progressed to the point where the main developers of it
 	    and many other members of the logging community are using it daily.  It's still pre-alpha but only
 	    because we keep thinking up things to add.
 	    </p>

 	  </td>
 	  <td>Scott Deboy and Paul Smith</td>
 	  <td>Significantly progressed </td>
 	</tr>

 	<tr>
 	  <td>Custom conversion characters in PatternLayout</td>
 	  <td>Users often want to add new conversions characters or
 	  override the existing ones. This should be made easy using
 	  new configuration directives. This feature would use the
 	  extensions to XML configuration language mentioned
 	  above.</td>

 	  <td>Ceki</td>
 	  <td>Completed, still testing</td>
 	</tr>

 	<tr>
 	  <td>Overture to other programming languages</td>

 	  <td><p>It is higly desriable to allow log4j ports in other languages
 	    to access log4j services in a language independent way. </p>

 	  <p>The use of a standard XML format to represent a LoggingEvent has been established and many of the related logging projects from
 	  non-Java languages have begun to support it.   In fact, a number of the log4j ports have volunteered to join Apache!</p>

 	  <p>Scott Deboy has completed work to create a fex XML-based Receiver
 	  classes that can accept logging events from an external source, and 'import' them into the local log4j environment.  </p> </td>

 	  <td>Ceki, Scott Deboy</td>
 	  <td>Significantly Progressed (if not completed)</td>
 	</tr>

 	<tr>
 	  <td>Strategy based rollovers</td>

 	  <td>
 	    <p>Contrary to our own DailyRollingFileAppender, Avalon's
 	      logkit has a nice and clean implementation for rolling
 	      files. See the
 	      <code>org.apache.log.output.io.rotate</code> package for
 	      exact details.
 	    </p>

 	    <p>Their implementation is based on strategies which are
 	    sub-components of appender. We will be able to configure
 	    such sub-components with the new XML configuration
 	    scripts.
 	    </p>
 	  </td>
 	  <td>Ceki</td>
 	  <td>Significantly Progressed</td>
 	</tr>


 	<tr>
 	  <td>Redesign of configure and watch architecture in
 	  configurators</td>

 	  <td>This is a very useful feature and the current architecture is not very good.

 	    <p>Contributions have been received by Mark Womack and others.</p>

 	    <p>See
 	      <pre>
      http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01390.html
      http://www.mail-archive.com/log4j-user@jakarta.apache.org/msg00666.html
      http://marc.theaimsgroup.com/?t=101010070500002&amp;r=1&amp;w=2
               </pre>
 	    </p>
 	  </td>
 	  <td>Mark Womack</td>
 	  <td>initial implementation</td>
 	</tr>

 	<tr>
 	  <td>Performance improvements to LoggingEvent serialization</td>

 	  <td>
 	    <p>Ole Dalgaard has shown that by implementing the
 	      java.io.Externalizable interface instead of
 	      java.io.Serializable in the LoggingEvent class, the
 	      speed of serialiazation is increased by a factor of 4 or
 	      more.
 	    </p>

 	  </td>
 	  <td>Ole Dalgaard?</td>
 	  <td>initial implementation</td>
 	</tr>
       </table>
     </section>

   </body>

 </document>
	<?xml version="1.0"?>
	<document>

	<properties>
	<author email="ceki@apache.org">Ceki Gulcu</author>
	<title>Release plan for log4j 1.3</title>
	</properties>

	<body>

	<section name="Plan? What plan?">

	<p>The following paragragh was adapted from the <a
	href="http://jakarta.apache.org/cactus/">Cactus</a> project's
	roadmap with the author's permission.
	</p>

	<p>Our users keep inventing better ways and adding new
	requirements. The downside is that our todo list keeps
	growing. The upside is that there is plenty of work to go
	around. If you are interested in participating, send an email
	on the log4j-dev@ mailing list stating your interest. You'll
	be promptly enrolled. We're always looking for help! Don't be
	put off if in the "Volunteer" column already has a person
	listed. Programming is fun, especially if it is done in a
	team.
	</p>

	<p>

	</p>


	</section>

	<section name="Workplan for log4j 1.3">

	<p>The workplan for log4j 1.3 is not final. It is included here
	to give you an idea of the future. The items are not listed in
	any particular order. As always, there is no scheduled
	release date. The lack of schedule suprises and disturbs some
	people. Writing good software, like good cooking, takes
	time. If we make you wait, it is to create a better and more
	reliable product.
	</p>

	<table class="ls" cellpadding="3" cellspacing="2">

	<tr>
	<th>Label</th>
	<th>Comment</th>
	<th>Volunteer</th>
	<th>Status</th>
	</tr>

	<tr bgcolor="DDDDDD">
	<td><b>test cases</b></td>

	<td>
	<p>Writing test cases is not the most sexy part of
	software development but it is one of the most
	important. Automated test cases allow us to catch bugs
	as early is possible. It is strongly recommended to add
	a new test case with each new feature or component.</p>

	<p>Existing <em>Perl</em> language based test cases have been
	migrated to junit (all-Java)based test
	cases. The new tests are placed under the
	<code>tests/</code> directory. It should be thus
	possible for participants in the project to understand
	the stucture of our tests and add tests for their
	components.
	</p>
	</td>

	<td>All committers</td>
	<td>ongoing effort</td>
	</tr>

	<tr>
	<td>Extensible XML configuration files</td>

	<td>
	<p>The DOMConfigurator is complex and not very
	flexible. It can only deal with elements that the
	developer knew about at compilation time. This has been
	an important drawback in the design of several appenders
	such as the the SMTPAppender and the
	RollingFileAppenders and its variants. These appenders
	need to delegate certain task to sub-components which
	are configured separately.
	</p>

	<p>The new JoranConfigurator being created by Ceki will be based on
	a new 'module' know as Joran, which can convert XML files into other objects based
	on rules. You can read more abouth Joran <b><u><a href="http://www.qos.ch/logging/JoranConfigurator.html">here</a></u></b>
	</p>
	</td>
	<td>Ceki</td>
	<td>Significantly progressed</td>
	</tr>

	<tr>
	<td>Log4j Domains</td>

	<td>
	<p>This is a very powerful and innovative concept that
	extends the notion of hierarchical loggers. It will also
	allow dynamic logging with pin-point accuracy. It was
	first suggested to me by Scott Stark of <a
	href="http://www.jboss.org">JBoss</a> fame.
	</p>
	</td>
	<td>Ceki</td>
	<td>design board</td>
	</tr>

	<tr>
	<td>Multiple implementations of Logger</td>

	<td>
	<p>Based on <code>RepositorySelectors</code> introduced in
	log4j 1.2, the user will be able to replace the
	<code>Logger</code> implementation. Several
	implementations will be provided offering different
	properties and functionality although none of the
	implementations will add new public methods.
	</p>
	</td>


	<td>?</td>
	<td>vaporware</td>
	</tr>
	<tr>
	<td>Plugins/Receivers</td>

	<td>
	<p>A Plugin framework has been designed and implemented.</p>
	<p>All of the currently developed plugins are "Receivers", which can be thought of as the reverse of an appender; something
	that <b>accepts</b> LoggingEvents from some external source.
	</p>
	<p>This has proven particulaly useful with the log4j ports, with the addition of the XML-based Receivers able to accept
	LoggingEvents generated from other languages (see "Overture to other programming languages" below)
	</p>

	</td>
	<td>All</td>
	<td>Significantly progressed</td>
	</tr>

	<tr>
	<td>Improvements to Chainsaw</td>

	<td>
	<p><a href="chainsaw.html">Chainsaw v2</a> development has now progressed to the point where the main developers of it
	and many other members of the logging community are using it daily. It's still pre-alpha but only
	because we keep thinking up things to add.
	</p>

	</td>
	<td>Scott Deboy and Paul Smith</td>
	<td>Significantly progressed </td>
	</tr>

	<tr>
	<td>Custom conversion characters in PatternLayout</td>
	<td>Users often want to add new conversions characters or
	override the existing ones. This should be made easy using
	new configuration directives. This feature would use the
	extensions to XML configuration language mentioned
	above.</td>

	<td>Ceki</td>
	<td>Completed, still testing</td>
	</tr>

	<tr>
	<td>Overture to other programming languages</td>

	<td><p>It is higly desriable to allow log4j ports in other languages
	to access log4j services in a language independent way. </p>

	<p>The use of a standard XML format to represent a LoggingEvent has been established and many of the related logging projects from
	non-Java languages have begun to support it. In fact, a number of the log4j ports have volunteered to join Apache!</p>

	<p>Scott Deboy has completed work to create a fex XML-based Receiver
	classes that can accept logging events from an external source, and 'import' them into the local log4j environment. </p> </td>

	<td>Ceki, Scott Deboy</td>
	<td>Significantly Progressed (if not completed)</td>
	</tr>

	<tr>
	<td>Strategy based rollovers</td>

	<td>
	<p>Contrary to our own DailyRollingFileAppender, Avalon's
	logkit has a nice and clean implementation for rolling
	files. See the
	<code>org.apache.log.output.io.rotate</code> package for
	exact details.
	</p>

	<p>Their implementation is based on strategies which are
	sub-components of appender. We will be able to configure
	such sub-components with the new XML configuration
	scripts.
	</p>
	</td>
	<td>Ceki</td>
	<td>Significantly Progressed</td>
	</tr>



	<tr>
	<td>Redesign of configure and watch architecture in
	configurators</td>

	<td>This is a very useful feature and the current architecture is not very good.

	<p>Contributions have been received by Mark Womack and others.</p>

	<p>See
	<pre>
	http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01390.html
	http://www.mail-archive.com/log4j-user@jakarta.apache.org/msg00666.html
	http://marc.theaimsgroup.com/?t=101010070500002&r=1&w=2
	</pre>
	</p>
	</td>
	<td>Mark Womack</td>
	<td>initial implementation</td>
	</tr>

	<tr>
	<td>Performance improvements to LoggingEvent serialization</td>

	<td>
	<p>Ole Dalgaard has shown that by implementing the
	java.io.Externalizable interface instead of
	java.io.Serializable in the LoggingEvent class, the
	speed of serialiazation is increased by a factor of 4 or
	more.
	</p>

	</td>
	<td>Ole Dalgaard?</td>
	<td>initial implementation</td>
	</tr>
	</table>
	</section>

	</body>

	</document>