At 11:02 11.06.2002 +0100, you wrote: >John Armstrong wrote: > > > > Your question is in a different tense to mine. You ask: > > > > "For instance, what part or parts of log4j ARE binary incompatible?" > > > > My question is: > > > > "what part or parts of log4j MAY BECOME binary incompatible?" > > > > At present the answer to this question is apparently "any of log4j may > > become binary incompatible". In two of your (Ceki's) responses you have > > stressed that various pieces of log4j may not become binary incompatible, > > but in saying this you seem to be very clearly reserving the right to break > > binary compatability in the future. I want to know if there is any > > possibility that your position on this point will change. > > > > I have made every attempt to define the problem clearly - if you tell > me the > > points I am being vague on I will be happy to clarify them. > >
>How about this for a start. > >The API for retrieving a Category / Logger and the API for logging >and checking whether logging is enabled should be fixed for all time. >Code which is going to be used in a variety of different situations >which are outside the control of the original author will probably >not use any of the API. >e.g. > Create an interface, or an abstract class which both Category > and Logger extend which defines the log (..) and is...Enabled (..) > methods. > > Provide an API which will return an instance of that type in a > similar way to how Category/Logger does now. > > Guarantee that that API will never be change in such a way as > to break backwards compatability. > > Modify all previous and current versions of log4j to support that > API. This may take a little while but it will allow new code and > old code to coexist. Sigh. -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
