Frank Schönheit - Sun Microsystems Germany wrote:
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.
I fear I do not get you. What kind of logger is "created and returned"?
A generic one, probably. How does client code use it? It has to
check whether the logger already has some log handlers added or not, add
some if necessary. Sounds strange.
[...]
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.
Yes, XInitialization behind the scenes of service constructors is a bad
hack (that will hopefully go away). However, it should not be too hard
to write a service implementation for a service like
service ConsoleHandler: XLogHandler {
specific([in] string encoding, [in] XLogFormatter formatter, [in]
long level, [in] long threshold);
generic([in] sequence<PropertyValue> arguments) raises
(IllegalArgumentException);
};
which could then nicely be called through a generic
createInstanceWithArguments (and should define a reasonable policy how
to handle missing and excess arguments).
[...]
- 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 ...
And how would that help us to implement a LogRecord filler that is
compatible with Java 1.3.1 (or current base line)?
[...]
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?
Functionality that allows client code to obtain the ID of the UNO thread
it is executing in would have to be offered in the interface of each UNO
language binding. (The functionality should generally be already there,
just not officially offered to client code.)
Thanks & Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
