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.
http://traxel.com/java/UnitTestLoggingEvent.java 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
