logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Bushman <...@traxel.com>
Subject Re: LoggingEvent Serialization
Date Wed, 21 Nov 2001 03:53:18 GMT
On JUnit:
Following is a pretty rough pre-alpha. It is currently
capable of reading a LoggingEvent, Category, and Priority
definition from a 1.1.3 jar file (pops a JFileChooser
to ask for the jar); using those to instantiate
a LoggingEvent; serializing it into a byte[]; then
reading that byte[] into a 1.2 LoggingEvent instance.


Successfully asserts loggerName against category name,
then wrecks when it gets to the fqnOfCategoryClass
assert (proving that this is an important step). Haven't
written all the asserts yet.

Fun stuff, I haven't worked with ClassLoaders before.

On serialVersionUID:
It's in there, but I'm currently ignoring it. I
completely agree that checking for a perfect match
makes a lot of sense; then you just call
defaultReadObject(), translate levelInt and you're
done. I'm not as excited about writing a custom
read method to match every known UID. The magic
attack isn't very expensive, and only requires tiny
additions from version to version. Your thoughts?

Going on vacation, more next week. Those who
are celebrating it: Happy Thanksgiving!

On Tue, 20 Nov 2001, Ceki Gulcu wrote:

> Robert,
>  If I understand correctly, LogJam is intended to test the performance
>of serialization and as a side effect can be viewed as a compatibility
>check. It would be very helpful to have a test suite performing more
>aggressive compatibility tests. Are we sure that log4j 1.2 can flawlessly
>read all fields serialized with log4j 1.1.3? To ensure future growth of
>the serialization compatibility test suite, the tests should be
>implemented using JUnit and run using a jakarta-ant as a junit task.
>  In the actual tests we could use multiple classloaders to load
>different versions of log4j classes, in particular different versions of
>org.apache.log4j.spi.LoggingEvent. We should try serializing a
>LoggingEvent to a stream and read it back using various versions of
>LoggingEvent class.
>  I also feel that we are missing a version tag when we serialize
>LoggingEvent. If we had such a tag, we could adapt the deserialization
>strategy depending on the incoming version. The genius of the current
.version is that it is generic and should guarantee serialization
>compatibility with future versions. However, what if it does not? What if
>LoggingEvent in log4j 2.0 is so different that it cannot read log4j 1.1.3
>events? I think the ability to vary the serializations strategy depending
>on the incoming version is a safe bet. What do you think? Regards, Ceki

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message