In fact, you have another choice, maybe not tantalizing, but possible.
Repackage the Log4J source files into your own packages. In that case, you remove your dependency on incompatible upgrades for all eternity, and your user does not necessary know that Log4J is involved. (I remember we did something similar with .vbx files eons ago, since there were constant variations of bugs, bug work arounds and bug fixes, and they were supposed to always go to a central place, hence next program installed a newer version and broke our bug work arounds.) Niclas On Tuesday 11 June 2002 16:18, John Armstrong wrote: > Thanks for the replies. I would like to summarize. > > There seem to be three basic views: > > 1) There is no problem (Ceki G�lc�, Anders Kristensen) > 2) Binary compatibility should be maintained to some extent, the question > is how (John Armstrong, Doug, Sean Hager, Niclas Hedhman, Paul Duffin) 3) > Work round it (Scott Miller) > > (Sorry if I have interpreted anyone's views incorrectly - [Scott says that > a standard interface wrapper around log4j would be nice - so perhaps he is > in camp (2) with an "ideally" after the "should"]) > > I don't really know how to progress from here. I need to make a decision > about what to do about log4j. Probably in the next month or so I will > decide whether to stick with log4j or implement some work > around/replacement. > > What are the timescales for making a decision on this issue? And if the > decision is to go for some form of binary compatibility what are the > timescales for deciding exactly what form that binary compatibility will > take (i.e. when will the API be designed)? > > John > > P.S. I will be incommunicado for about 1 week, please do not think that I > have lost interest in this question just because I stop participating for a > while. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
