Table of Contents
There is following trouble with logging when implemented in Log4J way. As there is no static mutable state and every capability should be transferred explicitly.
On one hand it is wanted to be able to log from almost any component, on other hand logging consume precious resources and should not be configurable by program, unless such capability will be explicitly granted.
Logger stream also needs to have special access to exception stack traces so this capability should come outside. Allowing everyone to access stack traces is potential security risk as it allow component to extract information on who is calling him and react differently depending on context.
Strong capability discipline require explicit passing logging capability to component and not allow it to configure it. Configuring logging component should be done from outside or with special capability. This regretfully excludes logging in base class library like in collection, but that could be useful for debugging. So base class library is left with exceptions and adding additional information to exceptions.
In this variant client will be able to check if message needs to be logged.
This variant is similar to previous one, but parameter is implicit and passed to every method. It is even not counted as parameter on byte code level and there is "get.logger" instruction rather then explicit parameter.
Logging is very important thing and this variant simply acknowledges this by supporting it in core of platform. In this sense logging becomes of the same level as memory management.
In this variant client will be also able to check logging level. I'm currently going to choose this variant.
Yet another variant is to implement logger with Dylan-like Exception handlers, in this case for logging an exception is risen, then processed by parent handler, this will allow debugging, but it will not allow efficient logging as code will not be able to learn if it needs to enlist logging exception, on other hand an optimizations could be provided specially for logging signals or set of possible signals could be limited on assembly loading like it were done in assertions for JDK 1.4.