You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ceki Gülcü <li...@qos.ch> on 2005/05/18 17:58:05 UTC
[logging] test cases 1 to 4
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!
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?
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] test cases 1 to 4
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] test cases 1 to 4
Posted by Ceki Gülcü <li...@qos.ch>.
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.
>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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] test cases 1 to 4
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] test cases 1 to 4
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2005-05-19 at 13:05 +1200, Simon Kitching wrote:
> 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. 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...
+1
(i think i know what you have in mind but i won't steal your thunder...)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] test cases 1 to 4
Posted by Simon Kitching <sk...@apache.org>.
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.
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. 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org