UNO Logging API

Hi,

looking for a possibility to implement some client-side
logging
facilities in our database drivers, I came across
css.util.logging [1] -
a UNO API which promises to provide exactly such
capabilities.

Unfortunately, there's no implementation for this API.
Furthermore,
trying to implement it revealed some shortcomings, which
cannot be
solved with the existing API, since it is already marked
"published",
and thus cannot be changed anymore.

I'd like to propose a new logging API, which is modeled
after the Java
logging API (though not (yet) as powerful).

Since this involves quite a few new types, I will not
introduce them
here in this mail, but I uploaded a zipped version of the
autodoc-generated IDL reference for the proposed
com.sun.star.logging
module. You can find it at [2].

Feedback to this proposed API is highly welcome.

Thanks & Ciao
Frank

[1]http://api.openoffice.org/docs
/common/ref/com/sun/star/util/logging/module-ix.html
[2]http://udk.openoffice.org/servlets/ProjectDocumentList


------------------------------------------------------------
---------
To unsubscribe, e-mail: interface-discuss-unsubscribeopenoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org

Frank Schönheit wrote:

> looking for a possibility to implement some client-side
logging
> facilities in our database drivers, I came across
css.util.logging [1] -
> a UNO API which promises to provide exactly such
capabilities.
> 
> Unfortunately, there's no implementation for this API.
Furthermore,
> trying to implement it revealed some shortcomings,
which cannot be
> solved with the existing API, since it is already
marked "published",
> and thus cannot be changed anymore.
If there is an API that is neither used nor implemented and
obviously
also not good enough: shouldn't we just remove it?

Ciao,
Mathias


-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/Gu
llFOSS
Please don't reply to "nospamformbagmx.de".
I use it for the OOo lists and only rarely read other mails
sent to it.

------------------------------------------------------------
---------
To unsubscribe, e-mail: interface-discuss-unsubscribeopenoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org

Hi Mathias,

> If there is an API that is neither used nor implemented
and obviously
> also not good enough: shouldn't we just remove it?

I'm all for it, but AFAIK, there's not process for this,
yet. For
instance, some build tools would need to be adjusted, since
currently, a
build in offapi checks the created type registry for
compatibility with
a released type registry - this would break.

To make things worse, css.util.logging is part of the UDK,
so the
restrictions for removing it are probably even higher than
in offapi.

I plan to deprecate the useless APIs, removing all
documentation from
it, and only pointing to the successor API.

Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: interface-discuss-unsubscribeopenoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org

Hi,

Sorry for being late to this discussion. I don't read those
lists 
continuously any more.

Frank Schönheit schrieb:
> Hi,
> 
> looking for a possibility to implement some client-side
logging
> facilities in our database drivers, I came across
css.util.logging [1] -
> a UNO API which promises to provide exactly such
capabilities.
> 
> Unfortunately, there's no implementation for this API.


This is not entirely true.

The configmgr backend service has logging capabilities built
around this 
API. In configmgr/workben/logger a logger component can be
built that 
takes this log output and dumps it into a file (or on
stderr).

If there is trouble with configuration parsing at a
customer/user site, 
this component can be installed (using the UNO package
manager) and 
voila - you get log output. The component is crude in some
respect (it 
is configured via environment variables and the log
threshold level is 
configured numerically), but it wouldn't take all that much
to make it 
into something usable.

> Furthermore,
> trying to implement it revealed some shortcomings,
which cannot be
> solved with the existing API, since it is already
marked "published",
> and thus cannot be changed anymore.
> 

I'm not sure which shortcomings you mean and I haven't
looked at your 
new proposal.

One shortcoming I recall from implementing the above (btw,
at that time 
I tried to get feedback on a more general logging strategy,
but did not 
get much of value) is how to obtain a logger for a certain
component or 
module. As I had nothing to generalize by, I took the
simplest solution 
for the one-module case I had at hand: the configuration
defines a 
singleton name, which it will use to get a logger. It
doesn't care how 
that singleton is populated.

The simple test logger I defined (I also have a
multi-platform binary 
package for interested parties) registers itself as that
singleton. Of 
course much more sophisticated solutions that merge and
filter log 
output from multiple components can also be used in that
place.

- Jörg

> I'd like to propose a new logging API, which is modeled
after the Java
> logging API (though not (yet) as powerful).
> 
> Since this involves quite a few new types, I will not
introduce them
> here in this mail, but I uploaded a zipped version of
the
> autodoc-generated IDL reference for the proposed
com.sun.star.logging
> module. You can find it at [2].
> 
> Feedback to this proposed API is highly welcome.
> 
> Thanks & Ciao
> Frank
> 
> [1]http://api.openoffice.org/docs
/common/ref/com/sun/star/util/logging/module-ix.html
> [2]http://udk.openoffice.org/servlets/ProjectDocumentList

> 



-- 
Joerg Barfurth           phone: +49 40 23646662 / x66662
Software Engineer        mailto:joerg.barfurthsun.com
Desktop Technology       http://re
serv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.co
m/software/sunray/
Sun Microsystems GmbH    http:/
/www.sun.com/software/javadesktopsystem/


------------------------------------------------------------
---------
To unsubscribe, e-mail: interface-discuss-unsubscribeopenoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org

Hi Joerg,

> Sorry for being late to this discussion. I don't read
those lists 
> continuously any more.

(Sigh. Not getting feedback for about two weeks, my CWS is
short before
QA by now.)

>> Unfortunately, there's no implementation for this
API. 
> 
> This is not entirely true.
> 
> The configmgr backend service has logging capabilities
built around this 
> API. In configmgr/workben/logger a logger component can
be built that 
> takes this log output and dumps it into a file (or on
stderr).

Didn't know that, I just looked for a registered service in
a complete
OOo installation. Also, telling my plans for an
implementation in some
larger developer meeting made nobody raise his hand, saying
"but there
already is one ...". Sigh, again.

>> Furthermore,
>> trying to implement it revealed some shortcomings,
which cannot be
>> solved with the existing API, since it is already
marked "published",
>> and thus cannot be changed anymore.
> 
> I'm not sure which shortcomings you mean and I haven't
looked at your 
> new proposal.

Configuration is exactly one of the shortcomings. I wanted
to allow
people to change the "output channel", both
programmatically and in the
configuration - which lead to stealing the LogHandler
concept from the
Java API. Also, when I started implementing the actual
output of a
single event, I noticed that it might be desirable to have
different
output formats - which lead to stealing the LogFormatter
concept from
the Java API.
(I can even imagine that users want to be able to filter the
output -
which means that I intend to steal the LogFilter concept
from the Java
API, too.)
(And yet more, the ErrorHandler in Java sounds like a
reasonable
(advanced) concept. Assuming that loggers are used in
low-level
components, there's not much other possibilities to report
errors in
e.g. opening the log file.)

Also, as outlined in previous discussions with Stephan here,
the
existing API has some strange concepts (XLogger::getLogger,
e.g.), which
do not make use (and in some respects contradict) modern UNO
API concepts.

> One shortcoming I recall from implementing the above
(btw, at that time 
> I tried to get feedback on a more general logging
strategy, but did not 
> get much of value)

Seems I missed it at that time, or didn't feel like
bothering with it.

> is how to obtain a logger for a certain component or
> module. As I had nothing to generalize by, I took the
simplest solution 
> for the one-module case I had at hand: the
configuration defines a 
> singleton name, which it will use to get a logger. It
doesn't care how 
> that singleton is populated.

Which is one more shortcoming. The old API has some (crude)
way to
retrieve named loggers, the new API makes this a central
concept. So a
given component can simply obtain a logger with a name which
is specific
to this component.


Ciao
Frank

-- 
- Frank Schönheit, Software Engineer        
frank.schoenheitsun.com -
- Sun Microsystems                      http://www.sun.com/star
office -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -

------------------------------------------------------------
---------
To unsubscribe, e-mail: interface-discuss-unsubscribeopenoffice.org
For additional commands, e-mail: interface-discuss-helpopenoffice.org