On Thursday, October 17, 2002, at 11:58 PM, Ceki Gülcü wrote:

At 15:05 17.10.2002 -0700, you wrote:
I do not know what all of the 1.2 dependent bits are, but it should be
possible to abstract those components into interfaces and create version
specific instances from a factory.  So, for the NDC bits, you can
abstract the ThreadLocal usage, and use a substitute (perhaps with a low
priority bg thread to clean up) on 1.1 and use a ThreadLocal for 1.2.

Seems plausible that this can allow Log4j to be compatible with 1.1, 1.2
+ more.

Any reason why such an approach would not work?
It is definitely feasible, it just takes time and energy. Bluntly put, I prefer to spend my time and energy on other things. If someone else wants to do it, they are free to work on log4j 1.2 or even fork.
i think that this is the crucial point - lack of developer energy. there isn't sufficient energy amongst the core team to push onwards and retain JDK 1.1 compatibility.

ceki has indicated that the 1.2.x release series will still be available for JDK1.1-compliant releases. if there are enough volunteers out there with the required time and energy then continuing the development of a JDK 1.1 compliant version, then that will happen. does anyone out there care enough?

- robert


--
To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>

Reply via email to