commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [logging] test cases 1 to 4
Date Fri, 20 May 2005 13:54:44 GMT
At 03:05 5/19/2005, Simon Kitching wrote:
>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.

In  static  binding,  the  facade  and the  implementation  are  bound
together at compile  time. So it's totally impossible  for client code
to find the facade but  not the implementation. Actually, if that were
not  the  case,  that  is  if   the  facade  was  found  and  not  the
implementation, or if the implementation was found but not the facade,
it would mean that something seriously wrong had gone within the JVM.

If the intent is to permute through all the possible combinations,
then that's a different matter. Wouldn't it be actually better to test
combinations that make sense?

>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.

Selecting static binding for the majority of cases but having a way to 
dynamically select factory sounds very promising.

>  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...

Ceki Gülcü

   The complete log4j manual:

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

View raw message