On Thu, 16 Aug 2001, Ceki G�lc� wrote:
> I agree that simplifying the log4j API offers advantages. Nevertheless,
> the log4j API can change only if the changes are backwards compatible.
I know someone will be happy to read that :-)
> Category class being a class and not an interface has some
> disadvantages. At the time, it was a deliberate decision in favor of
> performance. If I had to do it again, I'd probably do it
> differently.
>
> As I said, I am all in favor of refactoring the log4j API but only if
> we can ensure a smooth transition path. Regards, Ceki
Actually, I totally agree with this, changing Category is a bad idea.
What I had in mind is getting some of the ideas from Logger, and create a
_new_ abstract class that contains the user part of Category. Then
Category can extend that class.
You can also create another (optional) LogConfiguration or LogManager
abstract class, with the methods the user can safely call, and have
Hierarchy extend this class.
All existing code will still work. Adding a "secure()" method that will
disable all unsecure configuration methods in Category will allow the code
to be usable without the danger of untrusted code messing things up. The
code will still be binary compatible, but if secure() is called the
unsecure methods will throw exceptions.
If the new Log class has a factory mechansim built-in, like in Jaxp or
a similar pattern, then someone can replace the implementation that is
used with either a simpler one, or a faster one, or something that deals
with sandboxing, or anything else.
( and in future we'll use Log instead of Category and LogManager instead
of Hierarchy :-)
Of course, this is just one choice. There are many other ways we could get
log4j to satisfy some (justified) requirements, while keeping backward
compatibility.
Costin
