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.
BTW, if it comes down to it, leaving Log4j 1.2 for 1.1 compatibility and
Log4j 1.3 for modern vms is cool too.
The approach has the merit of being the least effort approach.
Personally I don't use 1.1 so I couldn't care less about support for it.
But I it is one of the features I mention when pitching Log4j vs. JDK
1.4crap to clients.
I think that you'll have plenty of good reasons with log4j 1.3. :-)
If it is possible to have Log4j 1.3 support both by abstraction, then I
would say that would be the way.
It is possible just not economic.
--jason
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>
