Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: [logging] Avalon log not Serializable?
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: commons-dev@jakarta.apache.org
In-Reply-To: <1140497991.3813.307.camel@localhost.localdomain>
References: <1140497991.3813.307.camel@localhost.localdomain>
Content-Type: text/plain
Date: Tue, 21 Feb 2006 23:58:27 +1300
Message-Id: <1140519507.3813.359.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2006-02-21 at 17:59 +1300, Simon Kitching wrote:
> Hi,
> 
> I've been checking whether all the standard Log adapter classes are
> Serializable. The Avalon logger declares itself to be Serializable, but
> my reading of the code indicates this won't work. Can someone
> confirm/deny this?

I've done some more work, and it sure looks like AvalonLogger is broken
for Serialization. It's had quite an interesting history.

Craig Mcc has also confirmed it looks broken to him.

Here are the options I can see:
(a) remove AvalonLogger from the JCL 1.1 distribution.
(b) remove Serializable marker interface from AvalonLogger
(c) on deserialize, try to handle things properly (we can under
some circumstances). If not possible, create a dummy Logger
object that just discards all output.

AvalonLogger was only added in the 1.0.4 release (and therefore
obviously was not *deprecated*). However the avalon project is
completely dead AFAIK. One potential issue is that the latest "stable"
release of Apache FOP is v0.20 which still uses avalon-framework. While
old, I expect Apache FOP is used in quite a few apps. And apps using
Apache FOP *might* redirect JCL via the AvalonLogger adapter to the
avalon logging system. Crazy but possible.

Option b is also reasonable to me. Serialization never worked for
AvalonLogger; any attempt to use a deserialized object would immediately
result in a NullPointerException. By implication, there are no systems
out there using serialization for AvalonLogger objects. And the
existence of the Serializable marker is not a compile-time
incompatibility (except in truly perverse code). So surely dropping the
marker won't do any harm. It does mean we can't claim "all standard log
adapters are Serializable" but I think we can live with that.

Option c doesn't look too hard; the avalon Logger interface is almost
exactly like the JCL Log interface so we could whip up a dummy class
like NoOpLog which we can create an instance of.


My preference in order would be: B, A, C. 
All seem feasable.

Comments?


BTW, I have checked for unit tests for Serializable behaviour. Log4j,
Simple and Jdk14 all have a unit test checking that a
serialized/deserialized instance works ok.

NoOp, LogKit and AvalonLogger do not have serialization unit tests. As
NoOp has *no* instance members of any sort a test doesn't seem
vital :-). I'm willing to create a serialization test for LogKit..

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org