Hi Stephan,
>> 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.
>
> But in your scheme the work is with the producer of the new logger, too!
> You need to register it. (When is that done?)
No, you just ask the pool for a logger with the given name. If it does
not (yet/anymore) exist, it will be created and returned. No overhead
anywhere, IMO.
>> 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.
>
> Hm, still looks hacky to me. (Maybe its a hint that different handlers
> have different parameters, so its not optimal to have that fixed set of
> attributes at the common interface. Encoding is also not universally used.)
No sure. The alternative would be something like
XHandlerWithEncoding : XLogHandler
{
[attribute] string Encoding;
};
FileHandler : XHandlerWithEncoding ...
XConsoleHandler : XHandlerWithEncoding
{
[attribute] int Threshold;
}
, which looks like overkill to me.
>> 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.
>
> Ah, the registry of available named loggers is configuration based (had
> slipped me if it was already mentioned).
No, not mentioned. Intentionally, since I am not sure whether this
really belongs into the API definition, especially since those APIs
originally were part of the URE (udkapi, meanwhile I moved them to
offapi as per your suggestion), and I don't think that talking about
OOo's configuration would a good idea in the URE - wouldn't it?
> Still, parameters could be
> passed generically via XInitialization instead of the component context.
Given that XInitialization is (mis)used for constructor initialization
as of today, this would imply that a handler service could either have
one or more constructors, or allow for attribute initialization, but not
both. Else, every possible combination of to-be-initialized attributes
would need to be mapped to a constructor, which would soon let the ctor
count explode. Or the ::initialize implementation would need to apply
some magic to determine whether it's called as part of the constructor
implementation, or as initialization.
Don't really like this idea, sorry.
(Yes, don't *really* like the context value idea, too. But it seemed the
one with the least disadvantages.)
>> 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?
>
> Would it make sense to replace class+method with a generic "context"
> string, to be freely used by clients to put into it whatever they think
> is relevant?
Hmm, this could do.
>>> - 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.
>
> (Not true for Java 1.4; java.lang.Thread.getId was introduced in Java 1.5.)
Lemme be nitpicking, please ;)
The LogRecord - part of the Java logging API since 1.4 - has a member
ThreadID. So, the *concept* of a thread ID existed before there was a
possibility to obtain it from a Thread object ...
> But those IDs can be rather meaningless for users, since they differ for
> a single UNO thread, depending on which language binding you are in.
That's true in some cases. However, when it comes to adding log code to
a component which is written in C++, as is the logger, then the ID has a
meaning. And the IDs might provide useful information in those cases.
>> Should the thread ID be a string instead, and callers be responsible for
>> formatting the thread ID as string?
>
> Why the callers? We could lift UNO thread IDs (which are strings) from
> a UNO implementation detail to proper citizens of the UNO environment,
> so the code that fills in a LogRecord could obtain such a thread ID.
Okay, how would this lifting look like? Simply declaring
LogRecord.ThreadID as string probably isn't sufficient?
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]
