Re: [Japi-devel] [Gridarta-devel] Future Logging System

[Christian H. <ch...@ri...>]

Hi dear co-devs,


though I currently prefer Log4J over java.util.logging, I have some new pla=
ns=20
about the logging system.

Personally I see multiple uses of logging. Or multiple aspects of the same=
=20
purpose.
Of course, one context is, as a developer, to know what's going on in your =
own=20
system.
But another purpose is that we, as developers, should also be able to extra=
ct=20
as much information as possible from log files sent to us by our users when=
=20
they encounter problems.

Because of that, I see the following requirements, which are not fully met =
by=20
existing logging systems known to me, neither by Log4J nor by=20
java.util.logging:
* Each message must be given a unique ID that can be used to uniquely ident=
ify=20
that particular log message.
* I18N/L10N of log messages, so users can understand them. (Currently we do=
=20
not have users that use Gridarta and cannot undstand English very well, but=
=20
this might change in future)
* Sometimes a unique log message is still used at more than a single source=
=20
code location. Therefore the output of a log must contain source file name=
=20
and source line number (such information is available in our builds).
* The interface for using the log API should be as easy as possible, that=20
means
** The decision whether something should be logged or not (whether the mess=
age=20
is included in the current log granularity) should be made as fast as=20
possible (that's a nice to have requirement, not a must requirement).
** The interface must support varargs for creating the log message for two=
=20
reasons:
*** Makes the interface easy and nice to use
*** Prevents formatting from taking place before the decision whether or no=
t=20
to log is made, thus removing many of the needs for checking the log level=
=20
granularity outside the logging system.


Additionally I've setup some further requirements for a logging system:
* The logging system should be usable as facade to Log4J or as facade to=20
java.util.logging or as standalone.
* The logging system should provide an SPI for generating formatted log=20
messages. It should come with the following implementations:
** fast, no formatting, just string concatenation
** use java.text.MessageFormat
** use java.util.Formatter
** use both java.text.MessageFormat / java.util.Formatter, using an=20
intelligent decision mechanism to choose which formatting system to use.
* The logging system should provide an SPI for getting the format string of=
=20
log messages. It should come with the following implementations:
** fast, takes the key as format string
** use a resource bundle
** use JAPI's ActionFactory
* The logging system should provide an SPI for generating the actual log. I=
t=20
should come with the following implementations:
** stream logging
** facade to Log4J
** facade to java.util.logging
* The logging system should be self-configuring using properties and such,=
=20
using a convenient default which suites most users.
* The logging system should use Enums for logging.
** The enum class should be choosable, but the logging system should provid=
e a=20
reasonable default.


Am I reinventing the wheel? Yes, definitely. But I'm reinventing the wheel=
=20
with tools and experience available that weren't for Log4J and=20
java.util.logging, mainly varargs.


Cu ;-)
=2D-=20
Christian Hujer
=46ree software developer
mailto:ch...@ri...
http://www.riedquat.de/
PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB