I've spent the day reviewing mail-list archives... very informative. I've got a few questions and comments regarding a common logging interface.
1. If anything is evident, it is that this issue is NOT going to go away. I'm confident that if I hadn't brought up the issue earlier this week, you would have seen someone else do it monday morning! I don't suppose we can resolve it this time around? I understand that it's going to take both a technical effort as well as a change in perspective of both parties, but perhaps the answer to (3) below might help... perhaps. 2. Requiring the Avalon framework's LogEnabled interface imposes a significant change to previous logging schemes. It appears that, in the simple case, every class requiring a logger must implement the LogEnabled interface. In addition, when such a class is created, the creating code must explicitly call enableLogging(). It doesn't appear that there is a default, so I presume that calling the function is manditory. I see this as error prone and dangerous. It may be that a default can be imposed by the AbstractLogEnabled implementation. BTW, AbstractLogEnabled doesn't seem very useful. Example: myServlet extends HttpServlet, and since Java supports only single-inheritance myServlet is now unable to extend the AbstractLogEnabled class. In a initial study of the merits of Log4J versus other logging schemes available 2 years ago, I specifically chose Log4J because it supported a better model for simple tools (run-once, command-line, whatever). While I can appreciate what is happening from the point of view of IoC, especially in the context of a server - it is not necessary or appropriate for simple tooling - it's unnecessarily complicated. Granted that my original proposition was in the context of an enterprise application where I would be concerned with the security issues, and granted that middleware such as AXIS should be concerned with these issues... I think the point I want to make here is that there are different requirements for different developers/projects, and your framework just isn't appropriate for many situation (but you knew that :-). On the other hand, your framework may be the key to the whole issue... 3. You express concern about IoC issues related to security. Please help me understand if/how those issues remain for someone using Avalon's framework with the Log4J wrapper. 4. A distinction has been made between an attack of the host environment (changing configuration files, file system, etc) and a run-time attack of the server environment. We agree that security of the first is beyond the scope of this conversation. Assuming that the second could happen, help me understand how the concerns over what occurs to the logging override more critical concerns (like how they got there in the first place, and what other havoc they might cause). Thanks! <ras> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
