commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: [logging] requirements and static binding
Date Sun, 01 May 2005 10:57:43 GMT
On Sat, 2005-04-30 at 00:35 +1200, Simon Kitching wrote:

<snip>

> Analysis of the effectiveness of static in the demonstration scenarios:
> 
> 1-4: static fails, but that's expected. When using the static approach,
>    you simply must deploy the static adaptor and the target library
>    via the same classloader. I don't see that this causes any
>    conflict with the requirements listed above.

this is the whole point :)

with the compile time static approach you have to deploy the libraries
correctly. that's the same with dynamic classloading. both static and
dynamic approaches work when they are deployed in perfect conditions.
the real question is how many of the difficult conditions are also
covered. static binding (in theory) covers far fewer of the possible
imperfect permutations than dynamic binding could. given an impl jar, it
would be possible for dynamic binding to (in theory) cover every case
with conventional context classloaders which static binding can and some
that static binding cannot.

it's all a big circle but hopefully now after this long journey, things
can be seen more clearly. we have reached again the original point of
departure and disagreement: does having to change your deployment in
some cases (by adding log4j to the classloader containing the JCL
implementation) count as a fatal flaw or is it simply a pragmatic way of
dealing with a difficult corner case?

i like static binding. it's clean and easier to understand than dynamic.
for child-first classloaders, the deployment configurations required are
much easier. but in a parent-first environment, difficult configurations
are required to allow static binding to vary on a per application basis
in a container. each approach has different strengths and weaknesses. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message