logging-log4php-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Habunek (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4PHP-161) All configurable components should report errors when given invalid values
Date Sun, 06 Nov 2011 15:50:51 GMT

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

Ivan Habunek commented on LOG4PHP-161:

I can see two problems with the above ideas:

1. In both cases, the configurator would have to know how to validate parameters. Currently,
this is not the case, and I would like to keep it that way. The object which is being configured
(appender/filter/whatever) is the only one which knows how to validate it's own parameters.

2. If one was to programatically configure log4php (without using the configurator), the parameters
should still be validated. For example, if I was to do this:

$appender = new LoggerAppenderFile();
$appender->setAppend("not a boolean");

I would like the appender to throw a warning, since the "append" property is boolean.

The only other solution I can see is to do this individually in each setter as it is done
at the moment (in places where it is implemented at all). And this means a LOT of code recycling.

I'm not a big fan of the base class solution, but it seems as the most economical one. Why
do you think it's such a bad idea?
> 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


View raw message