[jira] Updated: (SPICE-6) Implement a syslog-like toolkit

The following issue has been updated:

    Updater: Peter Donald (mailto:peter-4lf8KW9E9MLMqX/[email protected])
       Date: Tue, 13 Apr 2004 2:01 AM
    Changes:
             assignee changed from Peter Donald
             environment changed to 
             timeoriginalestimate changed from 0
             timeestimate changed from 0 minutes
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://jira.codehaus.org/secure/ViewIssue.jspa?key=SPICE-6&page=history

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/secure/ViewIssue.jspa?key=SPICE-6

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: SPICE-6
    Summary: Implement a syslog-like toolkit
       Type: New Feature

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Spice
 Components: 
             NewComponents

   Assignee: 
   Reporter: Peter Donald

    Created: Tue, 25 Mar 2003 7:05 PM
    Updated: Tue, 13 Apr 2004 2:01 AM

Description:
logging configuration in Phoenix and a few other apps. Unfortunately the logging now is more oriented towards the developer rather than the end user. I am currently writing up a bunch of documentation and this has become painfully obvious to me. So I was planning on putting together something that would make logging easier for admins.

One of the best systems for admin style configuration is Unixs syslog. While each different syslog daemon has a slightly different format for configuration I have attached a representative format from a Mandrake linux.

You will notice that each line defines what a category (such as kern or news) and a priority (such as debug or warn). Under syslog the categorys are fixed and so are the prioritys.

I want to use the same sort of ideas but convert it into xml and allow user defined sets of levels. I was thinking about having a configuration format such as 

<logging version="1.0" packages="org.spice.logconf.lib">

  <destination name="dest1" type="File" target="/var/logs/myapp.log"/>
  <destination name="dest2" type="RotatingFile" target="/var/logs/dest2.log">
  ...config goes here...
  </destination>

  <channels destination="dest1">
    <include name="*.auth"/>
    <exclude name="http.*"/>
    <include name="network.encoder" priority="WARN"/>
  </channels>
</logging>

To use this you try to instantiate each destination by appending its Type to the list of packages and then with out any package prefixes. In this case dest1 would try to instantiate "org.spice.logconf.lib.File" and then "File" destinations. Each destination is then attached to loggers that are specified in channels declaration.

Another possible configuration format being.

<logging version="1.0" packages="org.spice.logconf.lib">

  <destination name="dest1" type="File" target="/var/logs/myapp.log">
    <channels>
      <include name="*.auth"/>
      <exclude name="http.*"/>
      <include name="network.encoder" priority="WARN"/>
    </channels>
  </destination>

  <destination name="dest2" type="RotatingFile" target="/var/logs/dest2.log">
    <config>
    ...config goes here...
    </config>
    <channels>
      <include name="*.auth"/>
      <exclude name="http.*"/>
      <include name="network.encoder" priority="WARN"/>
    </channels>
  </destination>

</logging>

It will use some of the ideas from the Excalibur logger toolkit but probably be more focused on providing admins ease of use and easy mechanism to validate logging configs. Some people have also asked for the ability to throw exceptions when a new logger category is created that has not been accounted for.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira