On Fri, 2005-05-20 at 15:54 +0200, Ceki Gülcü wrote: > 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?
no: this really hits to the heart of the problem. one man's corner cases are another's fatal flaws. the only chance of making real progress is to enumerate and deal with all possible combinations, not just those that make sense to developers here. of course, fixing combinations which make no sense is another matter: in some cases, it might be better to note that they not reasonable and describe the consequences... > >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. +1 being able to use both static and dynamic binding solutions where each makes more sense has (for a while) been my only hope of making real progress. i have some ideas that have been building for a while but i think maybe slf4j would be a better forum to address them. (i should be more active for the next few weeks that i have been for last month.) i'd also like to hear simon's proposals first. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
