Here you will find some of the planned features of AceLogger.

  • Asynchronous formatting and IO: that's possible by using Java 5 and newer, cause we can intercept the virtual machine shutdown, and so guarantee that all pending data would be "flushed".
  • An API using "varargs": so you don't need to worry about formatting all of your text, we will format that if the logging message is suitable for logging. It also eliminates the cost of "string concatenation" if the message were not going to be logged.
  • The possibility to log "uncaught" exceptions: again, only possible by using Java 5 and newer.
  • Configuration on demand: we'll use MBeans to access the configuration at runtime, so it'll be possible to activate or deactivate a logging category at runtime even remotely.
  • Mapping between objects and it's logged representation: it would be very useful, and by being independent of the "toString()" method, we gain in productivity. It would be possible to have a "user" object mapped to an IP address in the logs, but mapped to it's "username" in the default "toString()" implementation.
  • Convention over Configuration: the framework will provide sensible defaults, so one would configure only what differs from the defaults.
  • Extensibility: by providing an implementation based in interfaces and hooks for some points in the system, like the moment before appending a message to destination.
  • Modularity: the framework is based in modules, a common usage scenario would lead to the usage of the core module only, but if there's some especial needs like e-mail notification, the e-mail module could be attached.
  • Multiple appenders and "output filters": a message can be logged to multiple locations, like a file and the "syserr" using different formatters and priorities. An appender can also be "triggered" depending on a certain message or metadata.
  • Message templating: there's no need to use only simple strings in log messages, you can define a template that will be formatted using the supplied parameters.