On 1/10/11 4:11 PM, Felix Knecht wrote:
Since I started to work on the server almost 6 years ago, I was
convinced that writing StackTraces in the logs was a error, as it could
fill the logs very quickly, and make them grow so fast that any valuable
message could be buried into millions of lines of stack trace.
If errors are swallowed or converted into other Exceptions it's always
not easy to trigger the real error cause. That's why I get used to log
an error when catching it - even when throwing afterwards a
transformed error.
I also do that. The closest to the origin, the better.
What about having a dedicated log file only for errors? Like this the
common log file would still be readable.
This is something worth discussing. In many projects I was working on
previously, I was used to define more than one logger :
- one generic logger for debugging purpose,
- one dedicated logger for things like DB connections, LDAP connection,
Network connection, EJB cration/removal
I do think that dedicated loggers can help, and are easier to manipulate
by an admin.
Currently, what we have in the server is a set of loggers based on the
class name. It's really difficult to know which logger to filter when
you only want to have information about, say, the ASN.1 layer.
I think having something like what OpenLDAP has - ie, multi-level
loggers, depending on which aspect of the server you are interested in -
is probably a must have.
One idea would also to be able to activate logs dynamically : changing
the log level, or the logger to use, by modifying the configuration,
would be great. As the configuration is now stored in the DIT, this is
an approach we could use (another way would be to use JMX, but here,
frankly, that would be overkilling and not persistent).
These ideas worth being discussed, that's for sure.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
