An xml-based socketappender is a good idea - I didn't write it because there were no 
serialization issues.  

What if we deprecated SocketAppender and provided an XMLSocketAppender (for use with 
an XMLSocketReceiver) in its place?

Scott

-----Original Message-----
From:   Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent:   Wed 9/15/2004 12:38 PM
To:     Log4J Developers List
Cc:     
Subject:        Re: refactoring of LocationInfo
At 08:55 PM 9/15/2004, Scott Deboy wrote:
>We're seeing a number of folks with problems using Chainsaw V2 and a 1.2.8 
>socketappender, related to the refactoring of LocationInfo into the new 
>package.
>
>There are workarounds that allow events to be processed by Chainsaw 
>without causing the ClassNotFoundException (re-order appenders to send to 
>socketappender first or remove %L from the pattern layout), but I'd like 
>to document and announce our official stance on serial compatibility 
>between 1.2.8 and 1.3.
>
>On one occasion I've made a change to loggingevent instance variables to 
>ensure serial compatibility, but MDC and LocationInfo are not working.
>
>My view is that unless we've marked something as deprecated, we should 
>maintain compatibility.

As far as I know, there is no way graceful way to refactor *internal* 
components from version to version and at the same time keep serialization 
compatibility between changed versions. In particular, there is no 
deprecation mechanism for serialization.

Our guarantee to users consists of maintaining compile-time and run-time 
compatibility between their code and various log4j versions. This means 
that if users decide to upgrade to 1.3 from 1.2.x, their code should run 
without problems. On the other hand, we *try* to maintain (but do not 
guarantee) Java serialization compatibility between log4j versions. This 
means that the user may not be able to mix various log4j versions on 
different machines. In particular, 1.3 and 1.2 are likely to be 
incompatible in their serialization.

On the other hand, the output of logging events in XML format should be 
independent with respect to internal changes. Output from log4j and the 
other Logging Services projects in XML should (must?) retain compatibility 
between versions.


>Scott

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




<<winmail.dat>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to