You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2005/04/15 20:33:57 UTC
to-do list
I've been distracted from log4j for a while by log4cxx and more
recently tax preparation. I hope to be able to spend devote some time
to log4j in the near future. In my working copy I have a couple of new
tests that I expect to commit before I start anything new:
EncodingTest was written primarily to support the implementation of
WriterAppender.encoding in log4cxx. The code under test in log4j is
fairly trivial, essentially the getters and setters, since encoding
itself is handled by java.io.Writer. However, the code under test in
log4cxx is fairly substantial and I really like having similar tests in
log4j and log4cxx.
LoggingEventTest primarily checks the serialization of LoggingEvent's
against reference copies. I expect these tests to evolve as I get into
the whole sequenceCount issue. However, at the present they do serve
as a check against unintended changes in the serialized form.
I'd like to get these in before the switch to Subversion, so please let
me know when that is imminent.
After I get back into it, the following log4j-related things seem to be
at the top of my list:
Port o.a.l.r.RollingFileAppender to log4cxx. I expect that to be
fairly clean but might suggest some changes to log4j.
Port JoranConfigurator to log4cxx. I expect that this will suggest
some changes to the log4j implementation.
Review the LoggingEvent related issues (sequenceCount and
serialization).
I have the sneaking suspicion that XMLLayout may not handle some edge
cases and will want to work up some tests to confirm it.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: to-do list
Posted by Curt Arnold <ca...@apache.org>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: to-do list
Posted by Ceki Gülcü <ce...@qos.ch>.
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. 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.
As for the lack of previous complaints. Here, I am complaining.
At 21:16 4/29/2005, Curt Arnold wrote:
>On Apr 29, 2005, at 11:23 AM, Ceki Gülcü wrote:
>
>>
>>Log4j and log4cxx are distinct code bases written in different
>>languages. I oppose any artificial attempts to make Java code mimic
>>C++ particularities, idiosyncrasies, deficiencies or a combination
>>thereof.
>
>It is the other way around, log4cxx attempts to mimic log4j in
>architecture and behavior. Since log4cxx is trying to mimic log4j
>behavior, it is very helpful if that behavior is defined and the easiest
>way to define that behavior is to add unit tests to log4j.
>
>For example, there were no tests that checked whether log4j responded to
>the encoding attribute on WriterAppender or checked whether the expected
>output was generated. 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. However, since log4cxx has to implement a
>whole lot more code to accomplish the same thing, it needed tests to check
>that implementation and the standard was whether it worked the same as
>log4j. Hence the desire to have parallel tests in both log4j and log4cxx.
>
>The tests I want to add to log4j are good normal JUnit tests, they were
>just motivated by log4cxx development priorities.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: to-do list
Posted by Curt Arnold <ca...@apache.org>.
On Apr 29, 2005, at 11:23 AM, Ceki Gülcü wrote:
>
> Log4j and log4cxx are distinct code bases written in different
> languages. I oppose any artificial attempts to make Java code mimic
> C++ particularities, idiosyncrasies, deficiencies or a combination
> thereof.
>
It is the other way around, log4cxx attempts to mimic log4j in
architecture and behavior. Since log4cxx is trying to mimic log4j
behavior, it is very helpful if that behavior is defined and the
easiest way to define that behavior is to add unit tests to log4j.
For example, there were no tests that checked whether log4j responded
to the encoding attribute on WriterAppender or checked whether the
expected output was generated. 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. However, since log4cxx
has to implement a whole lot more code to accomplish the same thing, it
needed tests to check that implementation and the standard was whether
it worked the same as log4j. Hence the desire to have parallel tests
in both log4j and log4cxx.
The tests I want to add to log4j are good normal JUnit tests, they were
just motivated by log4cxx development priorities.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: to-do list
Posted by Ceki Gülcü <ce...@qos.ch>.
Log4j and log4cxx are distinct code bases written in different
languages. I oppose any artificial attempts to make Java code mimic
C++ particularities, idiosyncrasies, deficiencies or a combination
thereof.
At 00:36 4/18/2005, Curt Arnold wrote:
>Having nearly identical tests (when the structure of the code is similar
>enough to allow that) makes it much easier to make sure that log4j and
>log4cxx behave similarly under the same conditions.
>Sometimes the resulting log4j tests are testing behavior that you could
>take for granted (like java.io.Writer's encoding support) and would appear
>to be overkill for log4j's needs. However, the implementation may be much
>more shaky in log4cxx and having similar tests in both log4j and log4cxx
>makes it easier to ensure that they behave similarly.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: to-do list
Posted by Curt Arnold <ca...@houston.rr.com>.
On Apr 17, 2005, at 1:43 PM, Ceki Gülcü wrote:
>
> At 08:33 PM 4/15/2005, you wrote:
>> I've been distracted from log4j for a while by log4cxx and more
>> recently tax preparation. I hope to be able to spend devote some
>> time to log4j in the near future. In my working copy I have a couple
>> of new tests that I expect to commit before I start anything new:
>>
>> EncodingTest was written primarily to support the implementation of
>> WriterAppender.encoding in log4cxx. The code under test in log4j is
>> fairly trivial, essentially the getters and setters, since encoding
>> itself is handled by java.io.Writer. However, the code under test in
>> log4cxx is fairly substantial and I really like having similar tests
>> in log4j and log4cxx.
>
> Why? log4cxx and log4j are distinct code bases. As far as I know, you
> are the only person who looks at both. If the implementation of a
> particular feature is done differently in log4j and log4cxx, then why
> should the test cases need to be similar?
Having nearly identical tests (when the structure of the code is
similar enough to allow that) makes it much easier to make sure that
log4j and log4cxx behave similarly under the same conditions.
Sometimes the resulting log4j tests are testing behavior that you could
take for granted (like java.io.Writer's encoding support) and would
appear to be overkill for log4j's needs. However, the implementation
may be much more shaky in log4cxx and having similar tests in both
log4j and log4cxx makes it easier to ensure that they behave similarly.
>> LoggingEventTest primarily checks the serialization of LoggingEvent's
>> against reference copies. I expect these tests to evolve as I get
>> into the whole sequenceCount issue. However, at the present they do
>> serve as a check against unintended changes in the serialized form.
>>
>> I'd like to get these in before the switch to Subversion, so please
>> let me know when that is imminent.
>
> The migration to subversion should take place in the very near future.
> So it should be considered imminent.
>
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: to-do list
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:33 PM 4/15/2005, you wrote:
>I've been distracted from log4j for a while by log4cxx and more recently
>tax preparation. I hope to be able to spend devote some time to log4j in
>the near future. In my working copy I have a couple of new tests that I
>expect to commit before I start anything new:
>
>EncodingTest was written primarily to support the implementation of
>WriterAppender.encoding in log4cxx. The code under test in log4j is
>fairly trivial, essentially the getters and setters, since encoding itself
>is handled by java.io.Writer. However, the code under test in log4cxx is
>fairly substantial and I really like having similar tests in log4j and log4cxx.
Why? log4cxx and log4j are distinct code bases. As far as I know, you are
the only person who looks at both. If the implementation of a particular
feature is done differently in log4j and log4cxx, then why should the test
cases need to be similar?
>LoggingEventTest primarily checks the serialization of LoggingEvent's
>against reference copies. I expect these tests to evolve as I get into
>the whole sequenceCount issue. However, at the present they do serve as a
>check against unintended changes in the serialized form.
>
>I'd like to get these in before the switch to Subversion, so please let me
>know when that is imminent.
The migration to subversion should take place in the very near future. So
it should be considered imminent.
>After I get back into it, the following log4j-related things seem to be at
>the top of my list:
>
>Port o.a.l.r.RollingFileAppender to log4cxx. I expect that to be fairly
>clean but might suggest some changes to log4j.
>
>Port JoranConfigurator to log4cxx. I expect that this will suggest some
>changes to the log4j implementation.
>
>Review the LoggingEvent related issues (sequenceCount and serialization).
>
>I have the sneaking suspicion that XMLLayout may not handle some edge
>cases and will want to work up some tests to confirm it.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org