On 10 Jan 2011, at 22:06 , Bram de Kruijff wrote: > 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.
My first reaction is to address this question to OSGi to find out why they did not include an "isLoggable" construct. My second reaction is that you seem to be using the LogService to trace and debug your code, which is something that is definitely worth discussing. One could argue that this is not what the LogService was meant for. Regarding named loggers and filtering. A log entry contains the bundle that logged the message and (optionally) the service. Those can be used to filter messages. That's what the LogListener is for. I would be hesitant to just dismiss the current LogService and replace it with a different one unless we can convince the OSGi alliance that this is a good idea. Greetings, Marcel
