Re: New extension to access liblog4cxx functions

Hi Gustavo, Thanks for your reply. My idea with this extension is to replace the Log4php (a php native library) by an extension built in C level. The problem with logger names and the inability to skip log from a whole package already exists when using Log4php, but I think I can improve my extension to solve this when using namespaces (thank you again). Log4cxx supports c++ namespaces, but I still have not done any effort to expose such functionality to php as I'm targeting 5.2 brach. The idea of separating the API and implementation, turning the extension a kind of core component for other frameworks is really a great idea. >* Please add a config.w32 file so that the extension can easily be built >on windows. I'll add the config.w32 as soon as possible, for now there is a whole VC6 project for compiling on windows here: http://code.google.com/p/php-logger-extension/source/browse/#svn/trunk/vc6 In the general, I'm just starting to have something functional, but already have a lot of things to document and test. I think the best for now Is really to keep the development at google code. I'll return whem the extension got more mature. 2009/12/12 Gustavo Lopes <glopes@nebm.ist.utl.pt> > On Fri, 11 Dec 2009 09:23:01 -0000, Jarismar Chaves da Silva > <jarismar.php@gmail.com> wrote: > > I'm developing a php extension that wraps the Apache's log4cxx ( >> http://logging.apache.org/log4cxx/index.html) as a php >> extension. >> For now the extension is hosted at >> http://code.google.com/p/php-logger-extension and a beta >> release is also >> available. >> I want to ask if it is possible to also make the extension available at >> pecl site. >> Please check it out and let me know what you think. >> > > I think the idea has some merit, but the mention of log4cxx reminds me of > log4j and the logging framework mess that plagues Java development. The > multiplication of logging frameworks is not a desirable outcome. > > Perhaps you could elaborate on how this is superior to PEAR Log and how > its introduction does more good than harm. > > I've gathered a few random points from a glance at the extension. > > * What convention do you propose for logger names? I see you use > Class::method in the examples. This may make some sense since you target > the 5.2 branch (no namespaces), but what about code outside a method > definition? That convention also denies the possibility of setting the > logging level for an entire library or package at one time -- the great > advantage of being able to define the logging level with arbitrary > granularity is kind of lost here. > > * Please add a config.w32 file so that the extension can easily be built > on windows. > > * It could be useful to separate the API from the implementation and be > able to plug it to e.g. the native PHP logging or PEAR logging. That would > at least mitigate the problem of logging framework multiplication. > > * I have no idea about the feasibility but perhaps implementing a PEAR Log > bridge would also be useful. This together with the last item would be > similar to the successful slf4j approach. > > -- > Gustavo Lopes > -- Jarismar C. Silva jarismar.php@gmail.com