The version of Apache log4j used by SoundHelix.

[[ 🗃 ^aEp6o apache-log4j ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/aEp6o

SSH: git clone USERNAME@vervis.peers.community:aEp6o

Branches

Tags

v1_2_11 :: src / xdocs /

plan.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<document>

  <properties>
    <author email="not@disclosed">Ceki G�lc�</author>
    <author email="not@disclosed">Mark Womack</author>
    <title>Release roadmap for log4j</title>
  </properties>

  <body>

    <section name="The Roadmap">

      <p>The log4j committers have adopted a roadmap for future releases
      of log4j.  This page documents that roadmap and gives you an idea of what
      to expect from future versions and timeframes for release.
      </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>

    </section>

    <section name="Release 1.2.12">
      <p>Expected timeframe: End of July, 2005</p>
      
      <p>Version 1.2.12 is planned primarily as a bug fix release.  It will be
      addressing major bugs where the fixes do not require api changes.  If you
      have a bug or problem that you feel should be addressed, please make sure
      that is reported in the log4j bug database and highlight it as a candidate
      for the 1.2.12 release.
      </p>
      
      <p>The log4j committers did decide to include one change in the 1.2 api
      for the 1.2.12 release: adding the TRACE level as a level choice with
      supporting methods to log messages for that level and check if the level
      is enabled.  The change is minor and should not cause problems with
      existing deployments that use version 1.2.12 throughout.  However, the
      committers reserve the right to not include it if it appears to break too
      much.
      </p>
      
      <p>It is expected that version 1.2.12 will be the last release for the
      1.2 branch, the next major release being version 1.3.  However, if a
      critical bug fix is needed, another version will be released.
      </p>
    </section>
    
    <section name="Release 1.3">
      <p>Expected timeframe: October, 2005</p>
      
      <p>The work for version 1.3 has been ongoing for a long time now, and it
      is time to button it up and let others take it for a ride.  Reviewing,
      stablizing, and testing the 1.3 code for release is the major goal for
      the log4j committers for this year.
      </p>
      
      <p>Version 1.3 is going to contain some very extensive changes and new
      features.  You should expect a number of api changes.  Early release
      alpha versions have been available for a while, and the releases will be
      accelerating as the committers review and cleanup the current code base
      for release.  As part of those releases, the committers plan to include
      jDiff reports that will clearly outline the changes and additions to the
      log4j code since the most recent 1.2.X release.  This should help you in
      seeing what might need to be reviewed or fixed in your own code related
      to log4j.
      </p>
      
      <p>Below is a table from previous documentation about the 1.3 work plan
      and it is somewhat out of date.  The committers will be updating this page
      with more and better documentation about what has changed, what has been
      reviewed, and what tasks remain as we work toward the 1.3 release.
      </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 G�lc� 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 G�lc�</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 G�lc�</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 G�lc�</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 G�lc�, 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 G�lc�</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>
[See repo JSON]