Hi Stephan,
>>>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.
Okay, perhaps I really should make the documentation about the
configuration-based initialization part of the IDLs ...
Current state by implementation is that a newly created logger has a
file handler associated with it, which writes to
$(userurl)/$(loggername).log. With this, a component which wants to log
something can simply do a
logger = LoggerPool.get().getLogger( <specificName> );
logger.log( ... )
Other than that, I'd expect loggers to be "module"-specific (where I use
"module" denoting a collection of components semantically coupled. For
instances, all components contributing to Base' JDBC driver
implementation would be a "module".). A dedicated instance within a
component would create and initalize the logger with a
component-specific name, all other parts of the module would only
instantiate the logger.
> 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).
Uh - createInstanceWithArguments currently also uses XInitialization,
but this is an implementation detail of the respective factories only.
(I remember that long ago, we implemented factories for the
configuration provider which in fact did something different.)
So no, createInstanceWithArguments is not an option here, since it would
assume that constructors are implemented using XInitialization, and thus
cement this hack for all time.
However, looking at XServiceDescription2 ... I did not try it, but this
looks indeed as if a generic handler instantiation code could check
whether the to-be-instantiated service supports a ctor taking a
sequence<PropertyValue> (btw. I definatily prefer NamedValue here and it
all similar cases, using PropertyValue is an unnecessary hack since we
have NamedValues.).
Assuming that the initialization happens using name-value pairs, it is
even possible to look for a ctor taking arguments with the proper
names/types in any order ...
Hmm, sounds tempting from an architectural point of view, but not really
like fun implementing it :-\
Assuming a proper ctor is found, how can I generically invoke it
(*without* using XInitialization directly)?
>>>(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)?
Hmm, yes, it wouldn't. But before somebody implements a logger in Java
1.3.1 (instead of using the existing implementation which doesn't have
this problem), Java 1.4 is the base line :).
The more since a Java logger implementation doesn't make any sense,
since here the ThreadID becomes meaningless, anyway - the Java UNO
bridge doesn't "preserve" the thread of the caller, as far as I know, so
every Java implementation obtaining the ThreadID would fill in nonsense.
> 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.)
Okay, so I'll make the ID a string, and for the moment fill it by
converting the numerical ID to a string myself. I'll then file an issue
(to you?) requesting the functionality you describe.
Overall, this leaves us with the following items
- make ThreadID a string
- document the configuration-based initialization pattern
- initialize via ctor using reflection, not context values
(assuming that a ctor can generically be called)
Did I forget something?
Thanks & Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
