On Apr 29, 2005, at 2:37 PM, Ceki G�lc� wrote:
I think we had this discussion before. In past cases, you implemented a particular feature in some way in log4cxx and later tried to impose the exact same feature in the exact same way in log4j.
Usually where there has been a request for a feature in log4cxx that does not exist in log4j and the feature has been reasonable and not C++ specific, my process has been to develop it for log4j, get it accepted by the log4j community (at least by lazy consensus) and then port it to log4cxx. The only time that I remember leading from log4cxx was with timezone specifiers in the date. The initial log4cxx implementation had timezones specified on the appender, after discussions it was decided that it would be better as %d{TZ} and that was implemented in log4j and then the log4cxx implementation was changed to be consistent with log4j.
If there is another instance that I'm forgetting, I'm sorry that I offended you. If you can provide some specifics, perhaps I can explain my actions and mend my ways.
The goal of the Apache Logging Services project is to achieve interoperability between various log4* implementations. Having identical implementations was never a goal. If you chose to mimic log4j in log4cxx, that is your choice and by your decision. No one is imposing it on you. Please grant the same liberty to the log4j project.
I inherited the design decision that log4cxx should be written in Java-like C++. Not that I'm disagreeing that decision though I think it overreached by trying to clone the Java theading model.
To be interoperable, both parties must respond in predicable ways to a particular set of circumstances. For example, Xerces-J and Xerces-C are both tested against common test suites (but adapted for language conventions). These common tests help ensure that, for example, Xerces-J does not report a document as invalid and Xerces-C reports it as valid. In addition to the common tests, I'm sure each have independent tests that test internal behavior.
In our case, there isn't an external standards body that has defined, for example, the interpretation of a log4j configuration file. The "correct" answer in almost every instance is to do what log4j does. Where there are adequate tests, log4cxx (or log4net) can adhere to this standard by passing the same tests (appropriately modified for platform differences) that log4j passes.
However, where there are no tests for a particular feature, then log4cxx needs to establish what log4j does so it can do likewise. The most direct way to capture this behavior is to develop tests for log4j (which is assumed correct since the user community would have likely complained if it wasn't) and then pass these tests. To keep the implementations in synch, it is beneficial if these tests get integrated into both implementations test suites.
As for the lack of previous complaints. Here, I am complaining.
I think you may be been responding to this statement:
There were no tests that checked .... For log4j development, that wasn't a bad state of affairs since (a) no one had complained and (b) the JVM did most of the work and likely did it right.
What I was trying to get at was that since log4j is well regarded and widely used, if there are no bug reports (complaints) then the code is usually doing the right thing in most cases. A presumption of correctness for established code that reduces the motivation to establish formal test cases.
I was trying to explain why there has not been the motivation to add the tests to log4j that would have benefited log4cxx development. Since established log4j code is presumed correct and is stable, it has survived with a fairly small amount of test coverage. Since log4cxx is rapidly changing, it really needs better coverage.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
