Hi Paul,
The versioning/serialization problem you mention is a quite generic and goes beyond
log4j.
The solution adopted by some APIs, in particular JMS, is to encapsulate most
parameters in a HashMap. This allows the underlying data type to be indefinitely
extensible. The disadvantage is that there is no longer any language level control
over parameters or methods.
For increased extensibility, we should add a small HashTable field to LoggingEvent.
This constitutes a nice answer to the extensibility problem albeit at the cost of some
(minor?) performance.
One a parallel track, we should make sure that the LoggingEvent class does not change
in backward incompatible ways. This is easier said than done. However, if backward
incompatible changes are deemed necessary, then not only are failures natural, but
also *desirable*.
Type safety is a fundamental property of strongly typed languages. It has nothing to
do with serialization or log4j. For this reason, I do not think that XML nor any other
technology can solve the versioning problem. Type safety and version independence are
incompatible demands. Regards, Ceki
At 09:39 04.06.2001 -0700, you 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
>
>
>Mike Dougherty <[EMAIL PROTECTED]>@smtp3.san.rr.com on 06/04/2001 12:36:20
>AM
>
>Please respond to "LOG4J Developers Mailing List"
> <[EMAIL PROTECTED]>
>
>Sent by: [EMAIL PROTECTED]
>
>
>To: [EMAIL PROTECTED]
>cc:
>Subject: Contributing
>
>
>
>Ok, now that I have embarressed myself on the user list maybe I should
>do something to change my ignorance of the codebase. I'm new to this
>process, so bear with me if I ask ignorant questions.
>
>I don't really have any features I'd like to add. But I want to help.
>Maybe I can help fix a bug or two. Should I just grab one, or should
>someone assign me one that'll help me get my feet wet.
>
>Thanks,
>/mike
>
>
>
>--
>******************************************
> Mike Dougherty -- Java Software Engineer
>******************************************
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
