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. http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111578975603542&w=2
It would be nice to note in the associated document which are scenarios that can be ignored as not reasonable.
My document here http://people.apache.org/~skitching/jcl-req.txt 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...
Regards,
Simon
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
