commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] test cases 1 to 4
Date Thu, 19 May 2005 01:05:45 GMT
On Wed, 2005-05-18 at 17:58 +0200, Ceki Gülcü wrote:
> Robert et al.,
> Your test cases are self-describing and easy to follow. One can hardly
> appreciate the work gone into putting in place something as delicate
> and tedious as these test cases. Well done!
Yes, I think so to.

> At first I was a bit puzzled that the static branch failed, and
> initially suspected the correctness of the test cases. However, given their
> construction, it is only normal for the static branch of tests 1 to 4
> to fail. It actually goes to prove that the test framework is doing
> its job correctly.
> However, if the intention was to compare dynamic binding versus
> static-binding, the setup of tests 1 to 4 is unrepresentative of the
> static-binding case, unless I am missing the point. For tests 1-4, you
> are demonstrating the fact that a parent class loader cannot see
> resources available to its children. Isn't this kind of obvious?

I think it's more a complete table of all combinations of 4 or 5
different factors. Not all of them are sensible, but it means that the
combinations are all complete.

As I note here, scenarios 17 and 21 (plus a few others) are simply not
reasonable ones, and can be ignored from any reasonable assessment of
whether a particular logging setup works or not.

It would be nice to note in the associated document which are scenarios
that can be ignored as not reasonable.

My document here
describes a specific scenario where I think static binding doesn't work
(see b4) - and it is quite a reasonable requirement I think. Of course
there are many scenarios where static binding is a very good solution.
I'm thinking that the best solution is one where the user can select
static binding for the majority of cases (ie deploy a simple jar that is
statically bound), but drop in a more dynamic factory class in the
problem scenario. Essentially, this results in merging of the current
SLF4J and JCL approaches, and I think it's entirely feasable (and even
without breaking existing code). This should give performance and
simplicity for most users (static) with the ability to use a more
dynamic approach in situation b4. See my post coming soon...



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message