You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4php-dev@logging.apache.org by "Florian Semm (Commented) (JIRA)" <ji...@apache.org> on 2011/11/06 16:10:51 UTC

[jira] [Commented] (LOG4PHP-161) All configurable components should report errors when given invalid values

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

Florian Semm commented on LOG4PHP-161:
--------------------------------------

It's a good idea to implement one "configurator", but I wouldn't do this with a god-logger class.

I think there are two solutions:

1. do it like the symfony2-framework 

Define the configuration in a class and validate the input with the configuration-class. See https://github.com/floriansemm/Log4PhpBundle/blob/master/DependencyInjection/Configuration/Configuration.php

This happens before you setup the appenders/filters/what ever

2. The LoggerAppender-class has a reference to a configuration class

When you setup the appender the configuration class "validate" this config-property. The man problem is here: you have to declare the possible config-parameters for the appender


Maybe it isn't the easiest way, but to create another "BaseClass" isn't a good idea. A mixed solution of your idea and my is also possible! :)


                
> All configurable components should report errors when given invalid values
> --------------------------------------------------------------------------
>
>                 Key: LOG4PHP-161
>                 URL: https://issues.apache.org/jira/browse/LOG4PHP-161
>             Project: Log4php
>          Issue Type: Improvement
>          Components: Code
>    Affects Versions: 2.1
>            Reporter: Ivan Habunek
>              Labels: configuration, validation
>             Fix For: 2.2
>
>
> This includes: appenders, layouts, renderers, filters (and any future ones).
> This is usually implemented in the property setter (sometime in activateOptions()). The problem is that the code for checking if something is an integer/boolean/string/whatever, and reporting an error is relatively long (cca 5-10 lines). We do not want to recycle this code for each and every setter.
> The proposed solution is to make a base class from which all configurable classes will inherit. This class will provide generic setters which include validation and error reporting.
> This is a mockup:
> http://pastebin.com/0h4M35Br
> I believe a solution to this issue should be included in 2.2 to complement the new configurator.

--
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