Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I find a some methods on the Logger class a bit strange. It is addAppender(), clearLog(), close() ,getNumberOfAppenders(), setLogLevel(Level logLevel), removeAllAppenders(), resetLogger() and other methods that effects the configuration of the logging framework.
First this implies that every Logger object can be individually configured (is that true?), this is certanllly not reflected in the configuration file. Second is it not the factory that should be configured so all the Loggers are effected. Third I believe in keeping the interface as small as possible and the Logger objects is the major frontend that most users of the logging framework ever see, and therefore I think it should be kept small, simple and clean.
As I stated in the topic this is an Discussion, and I am fully aware of Johans wish to do a 2.0 release of the micrologger soon. I still believe this is worth discussing
I totally agree with you; the Logger class should be kept small and simple (to use). But let me explain what my design ideas are.
BTW It is possible to do individual configuration of Loggers in Microlog. This is an asked for feature that was introduced in Microlog V2. **If you look closely, you find examples on how to use it. See the micrologV2.properties and the PropertyConfiguratorMidletV2**
First of all I made Microlog to be compatible with Log4j where plausible and where it makes sense. This is why there are "strange" methods like addAppender().
But there are two methods that you mention that is not part of the Log4j API:
The resetLogger() is now made package private since it is not to be used the the end user. The getNumberOfAppenders() is used by the PropertyConfigurator.
If the PropertyConfigurator is moved to the core package, methods like the getNumberOfAppenders() could be made package private.
One might also discuss whether Microlog needs support for manual configuration. If we decide to only support configuration through file, some of these methods could also be made package private. But I still think they are needed by the PropertyConfigurator.
I have done some small cleanup in Logger. This is now committed to the source code repository.
I have not decided of how to solve these issues in the Microlog V2.
please notice that I have simplified the public API in version 2.0.2. The Logger class should a little bit simpler than it was before your post.
We might consider removing the manual configuration, if this is still considered a problem.