Hi Stephan, > - Should not the singleton be called "theLoggerPool" instead of > "LoggerPool"?
A singleton I introduced to this list some time ago (IIRC, it was the OfficeResourceManager) used the same naming scheme. At this time, you asked the same question, but we agreed that it's not strictly necessary to use the "theFoo" scheme at this time. (Or, more precise, the question whether we should get rid of the "theFoo" convention was not answered.) This time, I hope to yak you down^W^W^Wconvince you again. > - Is the LoggerPool overkill? no, IMO. > (Why not theDefaultLogger as a singleton > and arbitrarily named loggers as services?) Since named loggers as services would give you less freedom (read: more work) in "introducing" a new logger. With the current way, you can simply ask the pool for a logger with a given name. Otherwise, you would need to explicitly define/implement your new logger service. > - What are the initial values of the Encoding, Formatter, Level > attributes of the ConsoleHandler, FileHandler services? utf-8, an instance of the PlainTextFormatter, and LogLevel::SEVERE. Added this to the service documentations. > (The > ConsoleHandler curiously uses a component context value to override the > Level, instead of a constructor argument No, the context value is used to determine the threshold: all events with a level higher or equal to this threshold are written to stderr, all below to stdout. This is different from the Level attribute, which determines which events are completely discarded and not logged at all. I consider the threshold to be too unimportant (read: too seldom to change) to make it a ctor argument. > , and instead of having this > consistent across attributes and services.) Hmm, what do you mean with "consistent across attributes and services"? Introducing an XConsoleHandler with an attribute Threshold? Also, please note that the XLogHandler documentation already asks services implementing this interface to look for the initial Encoding/Formatter/Level values in the context. So in some sense, the ConsoleHandler is consistent with the interface it implements. Basically, there are two reasons why I chose this context-based initialization: First, it's again similar to the Java API, which also allows retrieving default values from various sources (see the LogManager documentation). Second, it allows me to put a nice configuration-based initialization mechanism in place :), where for a given named logger, the user can configure initial settings (abstract name-value pairs, as far as the configuration and the code reading it are concerned) for a handler, which at instantiation time are used as context values. > - LogRecord members SourceClassName, SourceMethodName (and XLogger.logp > parameters SourceClass, SourceMethod, curiously with different names): You're right, I changed the parameter names to equal the member names. > If at the level of UNO, class does not make sense. If at the level of > implementation, neither class nor method make sense in general. Not sure I get you here - for nearly all our language bindings those concepts in fact exist. Do you suggest getting rid of logp completely? Should "Class" be renamed to "Component"? Should logp get a documentation that it might not make sense in all implementations? > - LogRecord member ThreadID: UNO's notion of threads is rather > abstract, there is no universal concept of mapping threads to hyper > values. (URP uses a mapping from threads to strings.) Well, all platforms on which the URE runs have a mapping from threads to hypers (vulgo: thread IDs), haven't they? I consider the thread ID a highly useful information in some situations, so I would not really like to remove it just because UNO so far has no concept for denoting a thread. Should the thread ID be a string instead, and callers be responsible for formatting the thread ID as string? Thanks & 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]
