Hi Stephan, > Sorry this feedback is rather late. Anyway, I am completely confused by > what you propose.
Some things in your mail make me think you read the old css.util.logging API, not the new one. Sure you visited http://udk.openoffice.org/files/documents/23/3959/logging.zip? > How is client code supposed to obtain an appropriate logger? css.logging.LoggerPool.get().getNamedLogger( someName ); > Is there a globally managed set of loggers from which clients > can choose? Yes - LoggerPool. > (For example, I would assume Java's static Logger.getLogger > to map to a UNO service constructor, or a method at an XLogManager > interface, but not a method at the XLogger interface.) In the new versions which I propose there is no method at XLogger which can be used to obtain another logger. The old API indead had an XLogger.getLogger, but I'd say somebody here copied from Java without caring to use proper UNO concepts ... > Excessive calls > to XLogger.logp are potentially expensive in every scenario, not merely > remotely (three strings are marshalled that are potentially not > needed when the given logging level is too fine). That's why the new API offers an "isLoggable( LogLevel )" - stolen from^W^Winspired by the Java API. > How exactly are > LoggingRemote and XLoggingRemote supposed to help here? Please elaborate. Those are not part of the new API, but only the old one. My understanding of those old remote versions is that somebody had in mind that calling via bridges - i.e. via the Java-UNO bridge - might result in the call "ending" in another thread then where it "started". Thus, an implementation of "log(p)" would not be able to obtain the thread id of the caller, thuse it needs to be passed. Something like this. While I to some extent think such a XRemoteLogger interface might be useful in some scenarios (but completely nonsense if e.g. the same logger is used across process boundaries), I decided to not define it for now in the new API. > (Also, Java has Levels as a fixed enum, not an open set of integers. > Why deviate from that? Do you think there ever will be need for more > levels than the given seven?) Not true - Java also explicitly allows extending the levels with own values - see http://java.sun.com/javase/6/docs/api/java/util/logging/Level.html: "It is possible for third parties to define additional logging levels by subclassing Level. In such cases subclasses should take care to chose unique integer level values ..." I think while it probably is seldom that one will extend the LogLevels, it does not do any harm to allow for it. 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]
