Hi Joerg, > Sorry for being late to this discussion. I don't read those lists > continuously any more.
(Sigh. Not getting feedback for about two weeks, my CWS is short before QA by now.) >> Unfortunately, there's no implementation for this API. > > This is not entirely true. > > The configmgr backend service has logging capabilities built around this > API. In configmgr/workben/logger a logger component can be built that > takes this log output and dumps it into a file (or on stderr). Didn't know that, I just looked for a registered service in a complete OOo installation. Also, telling my plans for an implementation in some larger developer meeting made nobody raise his hand, saying "but there already is one ...". Sigh, again. >> Furthermore, >> trying to implement it revealed some shortcomings, which cannot be >> solved with the existing API, since it is already marked "published", >> and thus cannot be changed anymore. > > I'm not sure which shortcomings you mean and I haven't looked at your > new proposal. Configuration is exactly one of the shortcomings. I wanted to allow people to change the "output channel", both programmatically and in the configuration - which lead to stealing the LogHandler concept from the Java API. Also, when I started implementing the actual output of a single event, I noticed that it might be desirable to have different output formats - which lead to stealing the LogFormatter concept from the Java API. (I can even imagine that users want to be able to filter the output - which means that I intend to steal the LogFilter concept from the Java API, too.) (And yet more, the ErrorHandler in Java sounds like a reasonable (advanced) concept. Assuming that loggers are used in low-level components, there's not much other possibilities to report errors in e.g. opening the log file.) Also, as outlined in previous discussions with Stephan here, the existing API has some strange concepts (XLogger::getLogger, e.g.), which do not make use (and in some respects contradict) modern UNO API concepts. > One shortcoming I recall from implementing the above (btw, at that time > I tried to get feedback on a more general logging strategy, but did not > get much of value) Seems I missed it at that time, or didn't feel like bothering with it. > is how to obtain a logger for a certain component or > module. As I had nothing to generalize by, I took the simplest solution > for the one-module case I had at hand: the configuration defines a > singleton name, which it will use to get a logger. It doesn't care how > that singleton is populated. Which is one more shortcoming. The old API has some (crude) way to retrieve named loggers, the new API makes this a central concept. So a given component can simply obtain a logger with a name which is specific to this component. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
