Simon Kitching wrote on Thursday, February 23, 2006 6:17 AM: [snip]
> Assuming that some Avalon loggers are *not* serializable then > there are > two problems. None of it implement Serializable, so your assumption is right. Since they don't have a default ctor they also cannot be the base of a serializable class (they are declared final anyway). > The first is that the AvalonLogger class in JCL has a constructor that > takes an avalon Logger object directly. In that case we don't > even have > a category name; we therefore have no way at all to obtain an > equivalent underlying Logger object on deserialize. > > The second is that the AvalonLogger constructor that takes a category > name has to assume that someone has called static > AvalonLogger.setDefaultLogger. This is pretty poor design for a start; > if they haven't then there is little option but to throw an exception > which is not good style for a logging library. The same problem occurs > on deserialize; we do have a category name but if the static > setDefaultLogger method hasn't been called then there's no > way to obtain > an underlying Logger. > > These two issues *can* be sort-of worked around by my proposed option > (c). However I don't really like the idea of silently > disabling logging. > > In short, I believe that Avalon logging in general, and the JCL > AvalonLogger in particular are not designed to handle > serialization and > so we just shouldn't be trying to support that. +1 If serialization is necessary, the user must use a log implementation, that supports it. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
