On Thu, 2006-02-23 at 13:07 +1100, Torsten Curdt wrote:
> > Here are the options I can see:
> > (a) remove AvalonLogger from the JCL 1.1 distribution.
> 
> Naaaa ...bad idea IMO. We would have to deprecate it first.

Ok.

> 
> > (b) remove Serializable marker interface from AvalonLogger
> 
> It's probably the best to fix it in the Avalon code.
> 
> It's old, it's becoming reviled just because it's Avalon
> ...but still some people are using it ...and some people
> still have commit rights to the old codebase :)

Are *all* avalon logger implementations required to implement
Serializable? If so, then we *can* indeed fix this simply by declaring
the underlying Logger object non-transient. However I have no idea how
this could be checked, who could be asked, etc. Personally I doubt that
any such requirement exists.

Assuming that some Avalon loggers are *not* serializable then there are
two problems.

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.

Cheers,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to