Richard Sitze wrote: > > 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.
In order to understand this, please read the docs on Avalon's site: http://jakarta.apache.org/avalon/developing-with-avalon.pdf Pay particular attention to the Lifecycle management section. Please note also that the docs on the site have not been updated yet to reflect the new LogEnabled interface. The principal is the same. Keep in mind that Avalon is built with IoC and SoC (Inversion of Control and Separation of Concerns). The document explains alot. > 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 this case, the HttpServlet is the ROOT class, therefore it creates the initial logger and reads the configuration used to set up the environment. This is the way Cocoon works. Once in a live system, yes any class that instantiates a LogEnabled class/Component must pass the Logger to the new class/Component. However, Avalon Excalibur has the tools to automagically manage the lifecycle of the Components that it manages. Thus, the actual number of calls to enableLogging() are minimized. Also, since all components implement the Component interface, they usually don't have a base class--meaning the implementation is free to use 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... You'd be surprised at how flexible the framework is. Don't be afraid merely because its different than you are used to. One of the things it allows you to do is to build your components and focus only on the concern areas applying to the Component. Again, Avalon Excalibur makes your life simpler because it provides a JUnit TestCase class that you can extend to test your components--complete with configurations, loggers, context objects, etc. It creates the environment, and provides the ComponentManager for you to grab and test your Component. In the end, you will see this actually _helps_ writing modular code that is easily extendable or pluggable. > 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. The wrapper classes are opaque, so there is no way for the client of the Logger instance to get at the Log4J instance. Therefore, the global access to all Categories is removed from that use case. In fact all the user can do is get a child logger (i.e. the Category name is "NAME.subcategory"). If the component decides to circumvent normal security and heirarchy of the Logger system by directly accessing the Category class, their code will break if a different Logging system is used. Therefore there is little to no incentive--because the environment cannot be guaranteed to be the same for every installation. Keep in mind that there is no such thing as absolute security. All you can do is raise the barrier to unauthorized access until it becomes not worth the trouble. By using a common practice throughout the entire framework, the framework becomes more modular and maneagable while simultaneously raising the barrier to unauthorized accesses. > 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). The concerns over logging are wether the intruder can add a new LogTarget that sends log events to their host machine. That means that a lot of precious information is going to a location you did not originally desire. Information is the key. With that information, they will be able to exploit potential weaknesses, or connect to the admin socket of a server, etc. Just as Logging is helpful to developers, it is also helpful to hackers. Plus it is the paranoid part of me comming out. -- "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
