Anthony Petrov wrote:
:
I have to say that that is not the best possible solution. For
instance, the sun.awt.X11 classes have many different loggers: for
focus-related code, for insets-related code, and so on. If a developer
debugs a particular kind of problem, (s)he doesn't need to look
through all the garbage that other loggers generate: it's just enough
to enable a particular logging facility (such as the
"sun.awt.X11.insets.XDecoratedPeer" for example) and examine what
(s)he really needs.
Combining all the output to just one logger will make debugging a
nightmare.
I would second to Oleg: improving the performance/design of the
existing logging classes at java.util.logging package would help all
applications at once.
I'm not familiar with the AWT implementation to have a strong view as to
how 6880089 is addressed. However, Mandy does raise a good question as
to why there is a need for so many loggers. I think one mail mentioned
there 85 loggers setup when running simple "hello world" Framer test.
Maybe they can be created lazily; maybe some of them aren't needed, but
at least there is a bug created so that someone can re-visit this. I
agree that any improvements to j.u.logging would be welcome too but that
doesn't solve the desire to decouple the dependency. For example, if the
libraries are broken up into a set of fine grain modules then why would
I need to have a logging module installed to run a simple client
application?
-Alan.
