Hi list, working on the fabric I have some problems/concerns with regard to our current convention of using the plain Felix OSGi spec LogService.
1) My main concern is performance due to the absense of a isLoggable construct. I am doing a lot(!) of extensive logging at LOG_DEBUG to make involving a lot(!) of method invocations, object creation and even some regular expressions. I need this to make the peer-to-peer messaging traceable and debuggable and I seriously dislike this limitation as this is a very performance critical component. 2) There are no named loggers and there seems to be no way to filter or even set loglevels based on source. The only "tool" available is the webconsole log interface which is pretty useless. Our LogHandler could be extended to make it a little less painfull. At this point I am thinking of the options... 1) Create my own custom fabric specific bridge that implements the missing functionality and is configurable through the fabric configuration. It solves my problem, its a local design decision for a specific concern so we do not need to discuss it much. However, I think it is a more generic issue. 2) Look into adapting Equinox Extended LogService that adresses both concerns through a custom API. (http://eclipsesource.com/blogs/2009/03/24/tip-osgi-log-service/) 3) Look into adapting PAX Logging that (seems to) adress(es) both concerns by provinding adaptors for most popular Logging framework and choose one as our default. http://wiki.ops4j.org/display/paxlogging/Pax+Logging 4) Create our own Amdatu LogService Extender (and try to submit it to Felix) that adresses both concerns. WDYT? Regards, Bram
