Is there any interest in a library to "Log" in model of Log4cxx? Thanks
Yes. I haven't used log4cxx but do use log4j regularly. I really like categories/"packaged class names" and being able to turn on logging for just a part of a program. Here are some things to keep in mind. 1) The existing boost logging library was made part of boost as a simple low level interface upon which more sophisticated logging could be built upon. As such you should consider building yours on top of it. That perhaps would go a long ways with other boosters. 2) C++ and Boost deserves something better than log4?. What I mean is try to learn from log4?'s mistakes and complications. a) If creating an application that host many other applications, tomcat/apache to the web applications they host, there is a need to have the options to allow multiple applications use the same logging with a discriminator or each sub application have its own logging and configuration in the same program or both b) name value property files are so yesterday and verbose. It would be nice to have something more structured. xml was nice in log4? but fell short because instead of having custom xsd's for loggers and layouts their configuration have been devolved to name value pairs. I personally like my arrays, lists, trees and graphs to look like such. Perhaps an XSD XML approach. Using JSON or better yet YAML would look even better. On 1/3/2012 8:23 AM, Renato Tegon Forti wrote:
Is there any interest in a library to "Log" in model of Log4cxx?
Thanks
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, Thanks for your comments. I am in process to develop this lib, and I will consider all of your comments. -----Mensagem original----- De: Jarrad Waterloo [mailto:jwaterloo@dynamicquest.com] Enviada em: terça-feira, 3 de janeiro de 2012 14:40 Para: boost@lists.boost.org Cc: Renato Tegon Forti Assunto: Re: [boost] Log Lib! Yes. I haven't used log4cxx but do use log4j regularly. I really like categories/"packaged class names" and being able to turn on logging for just a part of a program. Here are some things to keep in mind. 1) The existing boost logging library was made part of boost as a simple low level interface upon which more sophisticated logging could be built upon. As such you should consider building yours on top of it. That perhaps would go a long ways with other boosters. 2) C++ and Boost deserves something better than log4?. What I mean is try to learn from log4?'s mistakes and complications. a) If creating an application that host many other applications, tomcat/apache to the web applications they host, there is a need to have the options to allow multiple applications use the same logging with a discriminator or each sub application have its own logging and configuration in the same program or both b) name value property files are so yesterday and verbose. It would be nice to have something more structured. xml was nice in log4? but fell short because instead of having custom xsd's for loggers and layouts their configuration have been devolved to name value pairs. I personally like my arrays, lists, trees and graphs to look like such. Perhaps an XSD XML approach. Using JSON or better yet YAML would look even better. On 1/3/2012 8:23 AM, Renato Tegon Forti wrote:
Is there any interest in a library to "Log" in model of Log4cxx?
Thanks
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'd recommend having a chat with Boost.Log's author. He'd probably have ideas about where to take it. On 1:59 PM, Renato Tegon Forti wrote:
Hi, Thanks for your comments. I am in process to develop this lib, and I will consider all of your comments.
.... Here are some things to keep in mind. 1) The existing boost logging library was made part of boost as a simple low level interface upon which more sophisticated logging could be built upon. As such you should consider building yours on top of it. That perhaps would go a long ways with other boosters. ...
On 1/3/2012 8:23 AM, Renato Tegon Forti wrote:
Is there any interest in a library to "Log" in model of Log4cxx?
What is status of Boost.Log? I don't want reinvent the wheel! Need some help? -----Mensagem original----- De: Jim Bell [mailto:Jim@JC-Bell.com] Enviada em: terça-feira, 3 de janeiro de 2012 15:51 Para: boost@lists.boost.org Cc: Renato Tegon Forti Assunto: Re: [boost] Log Lib! I'd recommend having a chat with Boost.Log's author. He'd probably have ideas about where to take it. On 1:59 PM, Renato Tegon Forti wrote:
Hi, Thanks for your comments. I am in process to develop this lib, and I will consider all of your comments.
.... Here are some things to keep in mind. 1) The existing boost logging library was made part of boost as a simple low level interface upon which more sophisticated logging could be built upon. As such you should consider building yours on top of it. That perhaps would go a long ways with other boosters. ...
On 1/3/2012 8:23 AM, Renato Tegon Forti wrote:
Is there any interest in a library to "Log" in model of Log4cxx?
On Tue, Jan 3, 2012 at 19:34, Renato Tegon Forti <re.tf@acm.org> wrote:
What is status of Boost.Log? I don't want reinvent the wheel! Need some help?
I remember Andrei Schemasev saying that help would be welcome as he have less time that he wants to work on this library. I think this is the most recent discussion : http://boost.2283326.n4.nabble.com/Boost-Log-plan-tt4145824.html Here is a discussion where Andrei explained the status of the library in lengths (this is only the first email, you have to read the rest): http://lists.boost.org/Archives/boost/2011/07/183719.php Joël Lamotte
In a recent research I see: ACE Log (Trace) Poco Log What impressions about these models? -----Mensagem original----- De: Jarrad Waterloo [mailto:jwaterloo@dynamicquest.com] Enviada em: terça-feira, 3 de janeiro de 2012 14:40 Para: boost@lists.boost.org Cc: Renato Tegon Forti Assunto: Re: [boost] Log Lib! Yes. I haven't used log4cxx but do use log4j regularly. I really like categories/"packaged class names" and being able to turn on logging for just a part of a program. Here are some things to keep in mind. 1) The existing boost logging library was made part of boost as a simple low level interface upon which more sophisticated logging could be built upon. As such you should consider building yours on top of it. That perhaps would go a long ways with other boosters. 2) C++ and Boost deserves something better than log4?. What I mean is try to learn from log4?'s mistakes and complications. a) If creating an application that host many other applications, tomcat/apache to the web applications they host, there is a need to have the options to allow multiple applications use the same logging with a discriminator or each sub application have its own logging and configuration in the same program or both b) name value property files are so yesterday and verbose. It would be nice to have something more structured. xml was nice in log4? but fell short because instead of having custom xsd's for loggers and layouts their configuration have been devolved to name value pairs. I personally like my arrays, lists, trees and graphs to look like such. Perhaps an XSD XML approach. Using JSON or better yet YAML would look even better. On 1/3/2012 8:23 AM, Renato Tegon Forti wrote:
Is there any interest in a library to "Log" in model of Log4cxx?
Thanks
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I only have heard about them in passing when researching CORBA or using the POCO C++ libraries for those not found in boost such as database, process, services, web and xml. If I recall the POCO logging is comparable or less than to the Boost logging and doesn't offer the categories features of log4?. I think you are on the right track by considering log4cxx. Just make it better. Learn from its mistakes. On 1/3/2012 1:39 PM, Renato Tegon Forti wrote:
In a recent research I see:
ACE Log (Trace) Poco Log
What impressions about these models?
My plan is build some thing like this: * Log System * Application System (Windows Service, Unix Daemon, Usual Application) ->Process Management * Plugin System (services model) : late bind dynamically extensible that will provide modular applications like an service that can be loaded in application container. Than a developer that need create a server, for sample: Extend for boost::application::server and in this it use boost::log . To create service (modular application) he extend of boost::service to create a service and plug this service in runtime on boost::application::server. Application can be configured using Boost.Program_options for sample. What do you think? Do you think that "this" is very specific, and violate: " The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost. Thanks On 03-01-2012 18:33, Jarrad Waterloo wrote:
I only have heard about them in passing when researching CORBA or using the POCO C++ libraries for those not found in boost such as database, process, services, web and xml. If I recall the POCO logging is comparable or less than to the Boost logging and doesn't offer the categories features of log4?. I think you are on the right track by considering log4cxx. Just make it better. Learn from its mistakes.
On 1/3/2012 1:39 PM, Renato Tegon Forti wrote:
In a recent research I see:
ACE Log (Trace) Poco Log
What impressions about these models?
Individually, many on boost have expressed the need for logging, application system, process management and plugin system. I think "generally useful" means boosters would want four separate configurable but easy to use library proposals rather than one mammoth proposal. Each library should be able to handle almost any task sent its way but still convenience functions, objects whatever that handle the 90% of use cases. Logging we have one just need yours build on top. While competitive libraries are welcome in Boost the results of acceptance and voting has been to the contrary. Application System: I don't know if yours is written but if not the POCO C++ libraries have one one that follows the boost license but unfortunately not a part of boost and needs revisions to use more boost libraries instead of their dependent POCO libraries besides stupid MFC class and function naming conventions. Boosters have been rejecting processing management libraries for as long as they have been screaming to have it. The odds are stacked against you. You may want to look at past failed attempts and the reasons why they were rejected. Collaborating in a team may work here where past attempts failed. This is desperately needed for the construction of tools such "automatic compilation and loading of shared libraries upon file change" or "dependency tracking/management". Tools arguably essential for the present and future success and competitiveness of Boost and C++. Once again POCO's C++ libraries provides this with the same need for changes. There may have been between 4 and 6 requests for comments on boost plug in systems in the past year. None have yet became proposals. Once again POCO C++ libraries provides this with the same need for changes. I am not advocating POCO C++ just highlighting much needed and welcomed additions to Boost. I am in the minority here but I would rather have 90% of something than 0% of nothing. For me, imperfect creations are welcome in Boost and not in the standard since I think of Boost as a proving ground. Others and the majorities standards are much higher than mine when it comes to C++ code. On 1/3/2012 4:33 PM, Renato Forti wrote:
My plan is build some thing like this:
* Log System
* Application System (Windows Service, Unix Daemon, Usual Application)
->Process Management
* Plugin System (services model) : late bind dynamically extensible that will provide modular applications like an service that can be loaded in application container.
Than a developer that need create a server, for sample:
Extend for boost::application::server and in this it use boost::log .
To create service (modular application) he extend of boost::service to create a service and plug this service in runtime on boost::application::server. Application can be configured using Boost.Program_options for sample.
What do you think?
Do you think that "this" is very specific, and violate: " The library must be generally useful and not restricted to a narrow problem domain." or this kind of system is relevant to boost.
Thanks
participants (6)
-
Jarrad Waterloo -
Jim Bell -
Klaim - Joël Lamotte -
Renato Forti -
Renato Tegon Forti
-
Rhys Ulerich