Error reporting and/or internal logging

[Ivan Habunek <iv...@gmail.com>]

Hi!

Just a quick introduction, my name is Ivan Habunek, I live in Zagreb,
Croatia, and I have made several small contributions to the project. I
hope to make more in the near future. At the moment, I try to fix
problems which annoy me personally.

I use exclusively XML to configure log4php and at times this can be
difficult because of:
a) lack of proper documentation for XML configuration
b) lack of any error reporting, as far as I can tell

I would like to help address these issues. Concerning the second
issue, there is a setting in the XML configuration (the debug
attribute in log4php:configuration node) which is supposed to turn on
'internal logging' (see
http://logging.apache.org/log4php/apidocs/index.html), but as far as I
can see, this does nothing. Looking at the code, it seems that this
setting is not even parsed in LoggerConfiguratorXml.

In my opinion, it would make log4php much easier to use if it would
report any errors encountered in runtime, especially when parsing the
configuration. I would like your help and advice on how this would be
best accomplished.

One option is just to trigger an E_USER_WARNING when an error is
encountered. The second option may be to use log4php itself to log the
error, although I'm not that familiar enough with the code base at
this point to propose a way to do this.

After the error is identified and reported, the offending piece of
configuration can either:
* be reverted to a default setting (e.g. when an invalid layout class
is specified for an appender, the default layout can be used), or
* discarded completely (for example if an invalid appender class is
specified, just ignore the appender definition).

What are your thoughts on this?

Regards,
Ivan

Re: Error reporting and/or internal logging

[Christian Grobmeier <gr...@gmail.com>]

>> Please feel free to add some documentation as patch. Just create an
>> new issue and attach it there. There are reasons why Log4PHP is
>> missing a -good- doc.
>
> I know, everybody prefers coding to writing documentation. For starters,
> I'll add some more examples of XML configuration to the appenders page on
> the site. That's where most people will look first.

Thats perfect. Actually I like to write docs, but I finally do not
have the time. Some more help on this project is appreciated, and I am
very glad you step up


> I think that log4php should at the very least report errors and warning when
> parsing the configuration file. Internal debugging might not be necessary.

True

> I was checking out LoggerConfiguratorXml, looking for ways to add some error
> reporting. The code for parsing XML is very ... non-linear. :)
>
> I presume the XML Parser extension was initially chosen for parsing because
> it is supported in both PHP 4 and 5. Is there any reason not to switch to a
> more user-friendly extension such as SimpleXML? I think it shouldn't be too
> much work to code, and the code would be much more flexible, not to mention
> more readable.

Actually this implementation hasn been modifeid to much when
refactoring Log4PHP to 2.0 version.
In the version you now face it was everything ready for PHP4 core
modules. After long time of zero
development we reanimated Log4PHP and tried to bring everything up for
PHP5. But this configurator "worked".
We didn't change much because there was so much work on all other
corners. But this does not mean I like what inside this one.

To be honest I would LOVE to see LoggerConfiguratorXml making use of
current PHP5 technologies like SimpleXml. Its not only more readable,
I also think its fatser because it works on C level. So, go for it,
and thanks much for it.

There might be other stenches around which need improvements. Feel
free to work on any of them if you find them. I think we agreed to
support PHP5. We have not agreed on a minor version, but I would think
5.2.x would be enough.  Maybe others have other thoughts on this.


> I am working under the assumption (and hope) that Log4PHP project does not
> support PHP 4. :)

Yes :-) You can also see it on the "private" keywords and other minor hints ;-)

>> If you would go for this one I think this would be great. Log4PHP is
>> not so easy enough as I (and maybe others) would like to see it.
>
> Great. I also think that this is a good step towards making Log4PHP more
> accessible to the general public.

Yes I think so.
Again, thanks much for your help and for sticking with the project.

Cheers
Christian

Re: Error reporting and/or internal logging

[Ivan Habunek <iv...@gmail.com>]

On 30.4.2010 23:29, Christian Grobmeier wrote:
 > Please feel free to add some documentation as patch. Just create an
 > new issue and attach it there. There are reasons why Log4PHP is
 > missing a -good- doc.

I know, everybody prefers coding to writing documentation. For starters, 
I'll add some more examples of XML configuration to the appenders page 
on the site. That's where most people will look first.

> There was such an option before r2.0. Log4J has this option too. But
> in the old code base it was badly readable and we doubted the sense of
> this "feature". We thought that Log4PHP needs to be so easy that a
> feature like "internal debugging" shouldn't be necessary. As a
> consequence we deleted the internal logging code out from the
> codebase. What you found is what we forgot. We should delete it out to
> finalize this step.

I think that log4php should at the very least report errors and warning 
when parsing the configuration file. Internal debugging might not be 
necessary.

I was checking out LoggerConfiguratorXml, looking for ways to add some 
error reporting. The code for parsing XML is very ... non-linear. :)

There are several problems with this method of XML parsing:
* it is quite difficult to implement error reporting (you have to 
examine the $state stack to determine which error message to use)
* the order of elements in the configuration is significant (then you 
get things like https://issues.apache.org/jira/browse/LOG4PHP-114).
* it's difficult to discard a part of the configuration in which errors 
were detected

I presume the XML Parser extension was initially chosen for parsing 
because it is supported in both PHP 4 and 5. Is there any reason not to 
switch to a more user-friendly extension such as SimpleXML? I think it 
shouldn't be too much work to code, and the code would be much more 
flexible, not to mention more readable.

I am working under the assumption (and hope) that Log4PHP project does 
not support PHP 4. :)

> I think E_USER_WARNING would be an option. Things like:
> set_error_handler("customError",E_USER_WARNING);
> will work then

OK, we agree on this one.

> If you would go for this one I think this would be great. Log4PHP is
> not so easy enough as I (and maybe others) would like to see it.

Great. I also think that this is a good step towards making Log4PHP more 
accessible to the general public.

Regards,
Ivan

Re: Error reporting and/or internal logging

[Christian Grobmeier <gr...@gmail.com>]

Hello Ivan,

> Just a quick introduction, my name is Ivan Habunek, I live in Zagreb,
> Croatia, and I have made several small contributions to the project. I
> hope to make more in the near future. At the moment, I try to fix
> problems which annoy me personally.

welcome to log4php. I know all your contributions and I am glad that
you have made your way into the project. I really would enjoy to see
you joining as a permanent committer to Log4PHP one. So please stick
with this project and keep on your great and valuable contributions,
be it code, thoughts or documentation.

> I use exclusively XML to configure log4php and at times this can be
> difficult because of:
> a) lack of proper documentation for XML configuration

Please feel free to add some documentation as patch. Just create an
new issue and attach it there. There are reasons why Log4PHP is
missing a -good- doc. It has docs, but they have been used from the
old and long time unmaintained Log4PHP project. Then we refactored it
and things changed. We tried to keep track with documentation, but
sometimes it didn't work. And last thing, the docs are similar to
log4j docs - and they are not exactly perfect either. I ever felt a
little bit lost on all documentation on the logging projects (i speak
of java and php, the other stuff i don't know well) so I am glad to
discuss all better options to make Log4php more user friendly and
easier to understand. If you need help on maven or the apt format, let
me know.


> b) lack of any error reporting, as far as I can tell
>
> I would like to help address these issues. Concerning the second
> issue, there is a setting in the XML configuration (the debug
> attribute in log4php:configuration node) which is supposed to turn on
> 'internal logging' (see
> http://logging.apache.org/log4php/apidocs/index.html), but as far as I
> can see, this does nothing. Looking at the code, it seems that this
> setting is not even parsed in LoggerConfiguratorXml.

That is true.
There was such an option before r2.0. Log4J has this option too. But
in the old code base it was badly readable and we doubted the sense of
this "feature". We thought that Log4PHP needs to be so easy that a
feature like "internal debugging" shouldn't be necessary. As a
consequence we deleted the internal logging code out from the
codebase. What you found is what we forgot. We should delete it out to
finalize this step.


> In my opinion, it would make log4php much easier to use if it would
> report any errors encountered in runtime, especially when parsing the
> configuration. I would like your help and advice on how this would be
> best accomplished.

I have heard some users demanding this feature and I had some bad time
to figure out the problem myself. So I appreciate and support this
effort. But I also think that the "internal logging feature" as we had
before wasn't so good to get it back again.

> One option is just to trigger an E_USER_WARNING when an error is
> encountered. The second option may be to use log4php itself to log the
> error, although I'm not that familiar enough with the code base at
> this point to propose a way to do this.

I think E_USER_WARNING would be an option. Things like:
set_error_handler("customError",E_USER_WARNING);
will work then

> After the error is identified and reported, the offending piece of
> configuration can either:
> * be reverted to a default setting (e.g. when an invalid layout class
> is specified for an appender, the default layout can be used), or
> * discarded completely (for example if an invalid appender class is
> specified, just ignore the appender definition).
>
> What are your thoughts on this?

I think option 2. I would like to avoid problems in a hot system
caused by the logging framework just because somebody misconfigured
it. So better do no harm.

If you would go for this one I think this would be great. Log4PHP is
not so easy enough as I (and maybe others) would like to see it.

Cheers
Christian


>
> Regards,
> Ivan
>