Long-term, we could use Sun's proposed JAXB
http://java.sun.com/xml/jaxb/index.html:
JAXB (previously known as Project Adelard) provides an API and tools that automate the mapping between XML documents and Java objects.
-Chris
----- Original Message -----
From: "Paul Glezen" <[EMAIL PROTECTED]>
To: "LOG4J Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 10:56 AM
Subject: Re: LoggingEvent Serialization (was: Re:
Contributing)
> 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]
>
