On Thu, 2005-05-19 at 13:05 +1200, Simon Kitching wrote: > On Wed, 2005-05-18 at 17:58 +0200, Ceki G�lc� wrote:
<snip> > > > 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. +1 but it also illustrates the point that (when approached methodically) there are cases (unreasonable or not) for each type of binding where they must fail. > 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. yes but i'm not sure i'd put it quite like that... there are several combinations (which ones differ for dynamic and static binding) which are not possible in theory. these are limitations of each particular binding method. rather than ignore them, i had it mind to create a troubleshooting document detailing them (and giving reasons plus alternative suggestions). users have no idea where to start when diagnosing problems: and this isn't just a function of dynamic binding. JCL is very widely used and users don't know that they need to start out methodically by finding every JCL jar and configuration file in their classpath. (static binding is just as vunerable to this kind of unreasonable misconfiguration. a methodical approach allows similar troubleshooting documents to be easily drawn up for static binding.) over the years, i've noted that users often consider some very unreasonable configurations as eminently sensible. what's obvious to those with good knowledge of classloading often appears mysterious and esoteric to those without such knowledge. i've come to the conclusion that code changes alone (or even binding changes) will never be enough: more technical documentation including methodical troubleshooting documentation is also needed. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
