Home → Repo ^aEp6o → Branch v1_2final Files → src → xdocs → plan.xml

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

trunk
plan.xml

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

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

  <body>

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

      <p>The following paragragh was adapted from the <a
	  href="http://jakarta.apache.org/cactus/todo.html">Cactus
	  project's roadmap</a> 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>With log4j 1.2 still in beta, the workplan for log4j 1.3 is
	obviously not final. It is included here to give you an idea
	of the future. The items are not listed in any particular
	order.
      </p>
      
      <table border="1" 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 are
	      gradually being 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 support for extensible configuration files will be
	    based on the code in commons-digester authored by Craig
	    McClanahan and Scott Sanders. They graciously granted
	    permission for the modification of their code and its
	    inclusion in log4j.</p>	      
	  </td>
	  <td>Ceki</td>	  
	  <td>design board</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>Improvements to Chainsaw</td>
	  
	  <td>
	    <p>Visualisation and dynamic filtering of logging event is
	      bound to be a very important area of activity in the
	      future. A number of important improvements to chainsaw
	      have been suggested.
	    </p>
	    
	  </td>
	  <td>Oliver Burn</td>	  
	  <td>under discusison</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>?</td> 
	  <td>not started</td>
	</tr>
	
	<tr>
	  <td>Overture to other programming languages</td>

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

	  <td>?</td> 
	  <td>not started</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>Kevin Steppe</td>	  
	  <td>not started</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>
      
      
      
    <section name="Workplan for log4j 1.2">
      <p>
	Here is workplan for the 1.2 release. 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 border="1" cellpadding="3" cellspacing="2">
	    
	<tr>
	  <th>Label</th>
	  <th>Comment</th>
	  <th>Volunteer</th>
	  <th>Status</th>
	</tr>
	
	<tr bgcolor="DDDDDD">
	  <td>More test cases</td>
	  
	  <td>We need more automated test cases to catch bugs as early
	    is possible.It is highly recommended to add a new test case
	    with each new feature or component.</td>
	  
	  <td>All committers</td>
	  <td>ongoing effort</td>	  
	</tr>


	<tr>
	  <td>Removal of deprecated methods</td>
	    
	  <td>Deprecated <code>setOption</code> and <code>getOption</code>
	    methods in appender and layouts should be removed.</td>

	  <td>Ceki</td>
	  <td>done</td>
	</tr>
	
	<tr bgcolor="DDDDDD">
	  <td>JDBCAppender</td>
	  
	  <td>
	    <p>We currently have two competing JDBCAppenders: one by
	    Thomas Fenner and the other by Kevin Steppe.</p>

	    <p>Kevin Steppe stood up and did it.</p>	    
	    </td>
	  
	  <td>Kevin Steppe</td>
	  
	  <td>done</td>
	</tr>
	
	<tr>
	  <td>Log4j in applets</td>
	  
	  <td>In order to minimize network traffic, the size of log4j-core.jar
	    needs to be reduced to at most 50KB.
	    
	    <p>Log4jME has been released. It's less than 20KB.</p>
	  </td>
	  
	  <td>Ceki</td>
	  <td>done</td>
	</tr>
	
	<tr  bgcolor="DDDDDD">
	  <td>Improved documentation</td>
	  
	  <td>Log4j documentation needs to be enhanced with configuration
	    examples and much more hand-holding.</td>
	  
	  <td>Ceki</td>
	  
	  <td>ongoing effort</td>
	  
	</tr>
	
	<tr>
	  <td valign="top">Mapped Diagnostic Contexts</td>
	  
	  <td>Mapped Diagnostic Contexts are similar to the NDC
	    except that the MDC is a string to string map instead of
	    a stack that the user sets when entering a special
	    context. The <code>PatternLayout</code> has to be
	    enhanced to support this by extending the %x pattern to
	    accept an argument.  Here is an example:
	    
	    <pre>
    ConversionPattern=3D%d %p %c %x{server} %x{host} - %m%n
	    </pre>
	    
	    User code:
	    <pre>
    {
       MDC.put("server", "totoServer");
       MDC.put("host", "someHost");
	      
       logger.debug("Hello");
	      
    }
</pre>
      will print:
      <pre>2000-01-24 10:00:00,000 DEBUG totoServer someHost - Hello</pre>

	    <p>To make MDCs truly user friendly
	      <code>ThreadLocal</code> variables are required. This
	      will allow the MDC to be inherited by child
	      threads. <code>ThreadLocal</code> are only supported
	      under JDK 1.2 and above. In JDK 1.1, the MDC will not
	      work but won't harm the user application either.</p>
	      </td> 
	  <td>Ceki</td> 
	  <td>done</td>
	</tr>

	<tr bgcolor="DDDDDD">
	  <td>Enhanced variable substitution support in DOMConfigurator</td>
	  <td></td>
	  
	  <td>Ceki</td>
	  <td>done</td>	  
	</tr>
	    
	<tr>
	  <td>FallbackErrorHandler</td>
	  
	  <td>The FallbackErrorHandler implements the ErrorHandler
	    interface such that a secondary appender may be
	    specified. This secondary appender takes over if the primary
	    appender fails for whatever reason.
	    
	    <p>The DOMConfigurator needs to be extended to support the
	      FallbackErrorHandler</p>
	    
	  </td>
	  <td>Ceki</td>
	  <td>implemented, requires further testing</td>
	</tr>
	
	
	<tr>
	  <td>Ensure backward compatibility of LoggingEvent
	  objects</td> 
	  
	  <td>To avoid deployment problems we must ensure that
	  LoggingEvent objects are compatible between 1.2 and 1.1.3.

	    <p>Robert Bushman has proposed a very innovative way for
	    solving this problem. See <a
	    href="http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01397.html">
	    http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg01397.html</a>
	    for further details.
	    </p>
	  </td>
	  
	  <td>Ceki</td>
	  <td>implemented, manually tested, requires automated test cases</td>
	</tr>
      </table>
    </section>

  </body>

</document>
[See repo JSON]
Clone

Branches

Tags

plan.xml
