paul,
XML based serialization could be useful for non-Java translations of log4j. Just one
of my far-fetched wishes... Ceki
At 10:56 04.06.2001 -0700, you wrote:
>I think the item Ceki has you working on takes priority over LoggingEvent
>serialization issues.
>
>As for the XML idea, that would solve the problem of version changes.
>Presently, log4j is not dependent on the user having XML parsers available.
>You need one if you want to use DOMConfigurator or if you want to use Ant
>to build the distribution. But otherwise it is not a requirement. Baking
>XML into LoggingEvent would mandate that anyone using log4j also bring
>along an XML parser for the ride.
>
>Of course, there are also the performance implications of using XML for
>each remote logging event. I'm not sure how much. But one would have to
>create and then serialize a DOM tree for each remote logging event.
>
>If this could somehow be done with object serialization, I think that would
>be the coolest. But I'm always open to alternatives.
>
>- Paul
>
>Paul Glezen
>IT Specialist
>Software Services
>818 539 3321
>
>
>Mike Dougherty <[EMAIL PROTECTED]>@smtp3.san.rr.com on 06/04/2001 10:35:27
>AM
>
>Please respond to "LOG4J Developers Mailing List"
> <[EMAIL PROTECTED]>
>
>Sent by: [EMAIL PROTECTED]
>
>
>To: LOG4J Developers Mailing List <[EMAIL PROTECTED]>
>cc:
>Subject: LoggingEvent Serialization (was: Re: Contributing)
>
>
>
>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]
>
>
>
>
>---------------------------------------------------------------------
>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]
