I read the whole discussion, and the bickering was fruitless. Let me help in the discussion a little bit.
Ceki, Please read the information on Inversion of Control (IOC) on the Avalon site. This will help you understand the importance of children not getting reference to parents. A point I make in my whitepaper (soon to be published on Avalon's site) is that IOC != security. It is important to note that IOC is a tool to achieve security. It helps to reduce the likelihood of a Masquerading attack. Part of security is knowing without a doubt the identity of the entities in a system. Part of security is making access to some information simply impossible. When Peter is talking about a higher security--by design--he is referring to this principle that is used throughout all the Avalon projects. Peter, LogKit is your baby, and you are very protective of it. However, some of your areguments come off as if they are from left field. An example is: "If however you are not accusing me of stealing ideas but instead of violating copyright then that is another thing altogether. I would like to see substantiated evidence that this has been the case for I do not apreciate slander." Ceki's comments were not meant as slander. Even I can read that much. Both of you, We should not be enemies. Both of you are very protective of your babies. This is good. However, if both of these projects are going to exist under the same umbrella--Apache--then there needs to be some symbiance between them. Honestly, I like Logkit because it is IMO easy to use, and packaged with Avalon. LogKit was part of Avalon before Log4J was part of Apache. I admit, I have not used Log4J due to the fact LogKit meets my needs. I also recognise that there are thousands of developers with the opposite view--that they like Log4J because it meets their needs and have no desire to switch. What I would like to see in the near future is a Logger interface that both projects can aggree to so that people who develop in Avalon can use their logger of choice. If JDK 1.4 supplies such an interface it might be worth investigating.
smime.p7s
Description: S/MIME Cryptographic Signature
