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 >
