The rules for XML serialization/deserialization can be external to
the LoggingEvent itself. Only when a remote logging event gets ready
to go across the wire, it would inspect the LoggingEvent object and
build the appropriate XML representation. This way, only the people
using remote logging will need an XML parser... just the same way
that only the people using the DOMConfiguration need an XML parser
today.
I recently did a distributed system using Apache SOAP precisely to
combat the kind of brittleness you're talking about with Java
serialization. In Apache SOAP, if the object you wish to serialize
to XML follows standard JavaBean conventions... it's automatic!
Otherwise, they have a very simple framework for writing your own
custom serialzers and deserializers...
Not that I'm necessarily endorsing using Apache SOAP in Log4J
(although I don't think it would be a bad fit...), but if you're
going to go the XML route, give it a look.
Anyway, my $.02...
- Tim
-----Original Message-----
From: Paul Glezen [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 1:57 PM
To: LOG4J Developers Mailing List
Subject: Re: LoggingEvent Serialization (was: Re: Contributing)
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
