Mailing-List: contact log4php-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4PHP Dev" <log4php-dev@logging.apache.org>
Date: Thu, 17 Nov 2011 19:15:51 +0000 (UTC)
From: "Florian Semm (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: log4php-dev@logging.apache.org
Message-ID: 
 <714874808.39774.1321557351250.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1391494223.10585.1317363945458.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (LOG4PHP-152) A rewrite of the
 configurator
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LOG4PHP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152247#comment-13152247 ] 

Florian Semm edited comment on LOG4PHP-152 at 11/17/11 7:14 PM:
----------------------------------------------------------------

some tests for

- LoggerConfigurator
- LoggerAppenderPool
                
      was (Author: floriansemm):
    some tests for

* LoggerConfigurator
* LoggerAppenderPool
                  
> A rewrite of the configurator
> -----------------------------
>
>                 Key: LOG4PHP-152
>                 URL: https://issues.apache.org/jira/browse/LOG4PHP-152
>             Project: Log4php
>          Issue Type: Improvement
>          Components: Code
>    Affects Versions: 2.1
>            Reporter: Ivan Habunek
>            Assignee: Ivan Habunek
>             Fix For: 2.2
>
>         Attachments: log4php.patch
>
>
> The current configuration system uses 3 separate objects to configure log4php - one for each configuration format XML, properties and PHP. This often caused inconsistencies in the way log4php is configured - the equivalent configuration would not produce the same results.
> The idea is to create a singe Configurator object which will _only_ take configuration as a PHP array. Then create several Adapter objects (one for each configuration format) which will translate the configuration from that format to a PHP array understood by the Configurator. This would make the Configurator the single class which configures log4php.
> The second goal of this action is to improve error reporting. Any configuration which cannot be parsed, or any invalid value in configuration should produce a PHP warning informing the user what's wrong.
> Thirdly, we should insure that the configurator does not throw any exceptions. Any errors should only result in a warning message so it doesn't break apps just because it cannot log.
> Lastly, we can standardize and document the PHP configuration format which exists already, but is not documented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira