[jira] Created: (SPSITE-7) Implement a syslog-like toolkit

jira-yCVjj/[email protected]
Newsgroups gmane.comp.java.spice.devel
Message-ID <[email protected]>
Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://jira.codehaus.org/secure/ViewIssue.jspa?key=SPSITE-7


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

     Status: Assigned
   Priority: Major

 Time Spent: Unknown
   Estimate: 0 minutes

    Project: spice-site

   Assignee: Peter Donald
   Reporter: Peter Donald

    Created: Tue, 25 Mar 2003 7:05 PM
    Updated: Tue, 25 Mar 2003 7:05 PM

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/Administrators.jspa

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



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.