Robert, At 19:45 19.11.2001 -0500, you wrote:
>Thank you for the author credit, I am honored. We are honored to have you as a contributor. >I'll be happy to thoroughly document the code. Good. >On readFields(): >According to the API spec, the only three cases >in which readFields() will fail are: > >ClassNotFoundException - if the class of a serialized object > could not be found. >- Presumeably this is not a problem as long as you are >only expecting backward read compatibility. Furthermore, >if we put some thought into the serialization now (make >sure the field names are ones you can live with forever, >as I think they are now), and stick to Java native >objects for any additional parameters in the future, >it is even possible to maintain forward read compatibility. > >IOException - if an I/O error occurs. >- Not much we can do about this regardless of using readFields() > >NotActiveException - if the stream is not currently > reading objects. >- This is a problem if there are legacy versions >of log4j that don't start their writeObject with >ois.defaultWriteObject(). I only looked at 1.1.3, >so I'm not sure if this was ever the case. > >Further, it's what Sun uses in their implementation >of ObjectInputStream.defaultReadObject(). If they're >using it, they must believe in it's reliability. :-) My question was actually about the opportunity of calling readFields. More like, "how do you know you can call readFields at that point?" In addition to your response, there is a partial answer at http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/input.doc1.html >On 1.1.3 transmission: >I was just using the application that's currently >under development at my office, which happens to >make extensive use of Log4j, and is currently deployed >with 1.1.3. But I've been meaning to write a demo >class for use with Chainsaw anyway. I'll toss it >in an executable jar with 1.1.3 and post a link. Sure. >On JavaWorld: >I love the idea! Who all should I clear the article >with before I submit it? (Apache? Jakarta? you?) There is no legal need to clear your article with anyone. The Apache Software License allows you to distribute modified versions of log4j (although you then loose the ability to use the Apache, Jakarta or log4j labels). I don't see why you could not write an article about an enhancement you made to log4j. Anyway, your article should not be centered around log4j. I think serialization compatibility is a topic of wider interest. Regards, Ceki >Agreed on startTime. Good point. > > >On Mon, 19 Nov 2001, Ceki Gulcu wrote: > >> I have looked at your code. You should definitely add yourself as an >> author. However, before I can commit the change to the CVS repository I >> need to throughly understand the code which I currently don't. Some >> extra documentation would not hurt. In particular, how do you know that >> in customReadObject(ObjectInputStream ois) >> method invoking ois.readFields() will work? Is this documented somewhere? >> >> private void customReadObject( ObjectInputStream ois ) >> throws IOException, ClassNotFoundException { >> >> final ObjectInputStream.GetField oisFields = ois.readFields(); >> ... >> } >> >> Could you share code that allows you to test that you can write a log4j >>1.1.3 LoggingEvent and read it back with 1.2? I suppose writing 1.2 and >>reading it back in 1.1.3 will not work. Otherwise, I quite like the idea >>of the code. IMHO, you should consider writing a javaworld article. >> >> I would not worry about startTime as long as the relative time between >>events generated on the same client is correct (which it will be.) >> >> Regards, ceki >> >> At 23:19 18.11.2001 -0500, you wrote: >> >I'm pretty happy with the new version posted at >> >http://traxel.com/tools/LoggingEvent.java > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
