Paul Glezen wrote:
>
> Hi Mike,
>
> Here is a problem I have been interested but haven't had the time to
> investigate it fully. You might want to check it out.
>
> Log4j uses a class called LoggingEvent to encapsulate the information sent
> to appenders from categories. For cases of remote logging, the event is
> serialized and sent across the network to a waiting server which
> deserializes it and processes it.
>
> If one is using log4j in a distributed environment, the client and the
> server have to be in synch as to the serialization version of the event.
> If a log4j upgrade involves changes to the event class, then all clients
> and servers must be upgraded at the same time. Otherwise object
> serialization errors occur. This can make log4j upgrades prohibitive in
> such an environment.
>
> It may be possible to make LoggingEvent serialization immuned to such
> changes. It would require some investigation, probably starting with a
> serialization document:
>
> http://java.sun.com/j2se/1.3/docs/guide/serialization/index.html
>
> Keep in mind that this is a JDK 1.3 doc. The solution should be compatible
> with other JDKs as well. Basically the goal is to allow the server to
> de-serialize an event even if the fields didn't match exactly. I'm not
> sure how possible or practical it is, but it's what I'd be working on if I
> wasn't still entrenched with the appserver package.
>
> - Paul
>
> Paul Glezen
> IT Specialist
> Software Services
> 818 539 3321
>
Sounds like and interesting project. I can start looking into it as soon
as I fix the bug Ceki suggested. Sorry he beat you to it (does that guy
sleep?).
I do have some initial thoughts on the subject. Maybe you have already
thought about it and dismissed it but here it is anyway.
This actually sounds like a perfect place to use XML over (or even
"for") serialization. Trying to read and write different class
definition versions to and from an ObjectOutputStream can get pretty
ugly.
However, if the information is in XML then either side can choose to
ignore non-required, unknown, and/or missing properties in the document.
I think you can actually still do this in the {read,write}Object()
methods so the user doesn't even have to know what's going on.
What I've done in the past is give objects like this a public toXML()
method (because this method maybe handy for users too, like toString()).
Which knows how to XMLify itself and any of its delegate objects (which
would know how to XMLify themselves), and so on. We would have to come
up with a document structure (DTD or Schema).
Maybe that's what you had in mind and I am just restating the obvious.
/mike
--
******************************************
Mike Dougherty -- Java Software Engineer
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
