Why BugWerk? $LOGGER_FRAMEWORK already exists?

It`s good, that $logger_framework exists and BugWerk is not about replacing it, at best it will supplement a feature. While logging frameworks abstractly deal with the documentation of the application runtime and the formatting of said informations, BugWerk concentrates on errors and the distribution of documenting reports, which is why it comes with a more specific data model.

Furthermore BugWerk is not about replacing proven frameworks and interfaces, instead it is about an easy integration into existing processes. For that reason, BugTrap, the Java Sensor Modules ships with an appender for the Apache Log4J Framework, which frees you from the requirement of writing own incident handling code in applications that are to be monitored. The support of further frameworks is under development.

Whats wrong with a simple mail notification?

This quite common approach has 3 drawbacks:

• it`s ineffective since every mail has to be read by a human. If you start to interpret the incoming mails programatically you can use BugWerk as well (BugWerk does exactly that: interpreting messages transmitted between applications)
• you need a SMTP service. You can either
  • provide an own SMTP engine with your application (which probably won`t pass a firewall)
  • provide credentials for an own, public SMTP service which is risky and insecure
  • or ask the end user for custom SMTP account data which overburdens most users or fails at lazy users
• due to high amount of redundant reports the the developer will stop to read the notification mails within a short time

My project has a public bugtracker!

This approach has it`s value in providing a feedback channel to the developer but its only widespread among open source projects as it reveals the internals and drawbacks of applications. Moreover it lacks automatization, fails at lazy users and preconditions technical competence on the end user side.