Logging
Hi,
Sorry, yet another long post.
I'll explain the proposed logging implementation.
There are four main classes.
Logger
This looks like the Logger in JBoss except instead of delegating
to org.apache.log4j.Category it has a "hot-swap" delegate.
LoggerDelegate
This is responsible for doing the logging.
It can perform the logging (like the Simple or the Null Logger)
or it can delegate to a "real" logger (like Log4j or java.util.Logging)
Perhaps a better name for this class is LoggerAdapter?
LoggerDelegateFactory
This is responsible for creating LoggerDelegate instances.
LoggerControl
This controls which Delegate is used by the Loggers.
The user can register a DelegateFactory to select the Logger they
require, any existing Loggers are automatically updated to the
new Delegate.
This class is used to create new Loggers with the correct Delegate.
Size
Currently the whole thing; the framework, simple logger, null logger
and log4j adapter is 26k unpacked (11k packed) although
feature set is incomplete (e.g. changing the logging level for a Logger)
These are the design principles:
1) JBossMX needs a logger, it should be able to report errors/warnings
etc without any configuration. It should also be possible to turn
on a debugging mode.
2) The logging should provide methods similar to existing loggers (e.g. log4j, JLog, java.util.logging).
I chose org.jboss.logging from the server module as a basis. The fact that it automatically configures the
simple logger means the bootstrap logger is redundant.
3) JBossMX is a library, the logging needs to adapt to the application
or user preferences.
MBean Configuration
I anticipate there will be something similar to Log4jService in JBoss
and similar configuration services for other loggers.
These configuration services would have the option to specify that
this is the type of logging required for JBossMX internal logging.
Multiple Applications
This is a tricky one. Log4j 1.2 allows multiple repositories to exist
so different applications can configure there own logging in the same
VM. But something has to select the relevant repository based on
the context. e.g. In JBoss the repository could be configured at
deployment time using the classloader as the context.
I'm not aware of other loggers with this technology.
We could provide something similar within our logging, but then it
ceases to be a light framework. We would probably have to go beyond
selecting the correct log4j hierarchy and actually switch the whole
logging framework (e.g. log4j -> java.util.logging)
This can be done providing there is a way for LoggerControl to
know what the Context is when asked for a Logger.
Something has to associate Contexts with logging frameworks/repositories.
Performance
The extra level of indirection is
logger->delegate->real logger
instead of
logger->real logger
I haven't done any real measurements on this.
The only measurement I've done so far is comparing the Simple Logger
and the log4j delegate when logging is not done (100,000 attempts)
When I profiled it, the JIT seems to think my framework isn't a
hotspot so mostly it leaves it interrupted and just compiles the
Simple Logger :-)
Packaging
Should the logger be org.jboss.mx.logging or org.jboss.logging,
it isn't really a management thing unless we are going
to get into context switches of logging.
Also, the log4j and other delegates could be packaged in different
jars for when size matters.
Regards,
Adrian
