|
|
Right Java tools for J2EE, Web Service, Grid and more |
| |Home | Products | Documents | Downloads | Purchase | Support | Company | Partners | Contact | |
Contents
There are two purposes of logging: log for auditing and log for debugging.
Log for auditing is part of business logic of the application. For example, you want record the resources that a user visited. You know what to log at the development time. This is relatively easy.
Log for debugging is not part of business logic. You do not really know what to log at the development time, so you just generally hard-code many logging statements, hopping some statements will record useful debug information when you need later.
AuditLog is log for auditing. It is a plugin for LimpidLog, which is log for debugging.
The purposes and the issues for these two types of logging are very different. Log for auditing generally generate much less data, so the easiness of use and reliability take higher priority than the performance.
AuditLog is a plugin of LimpidLog. A plugin when you run your application using LimpidLog. A plugin when you use GUI manager of LimpidLog to manager LimpidLog.
AuditLog is a plugin of LimpiLog. AuditLog will not work without LimpidLog.
The application must run using Java 1.5 or later, not 1.4.
The GUI management can run using Java 1.4, 1.5, or later.
When you start your application or application server
. When you start your application using LimpidLog, you need specify an option of LimpidLog:
pluginClassName=auditlog.AuditLog
AuditLog is packaged as a jar file as auditlogXXX.jar, where XXX is the version number. You need to specify where is the jar file of AuditLog. For example:
java -javaagent:limpidlog.jar -cp auditlog100.jar test.LiveTest
LimpidLog will automatically loads AuditLog.
When you configure AuditLog
AuditLog is a plugin of LimpidLog. The GUI manager of LimpidLog will automatically detect AuditLog and show the Plugin Panel of AuditLog.
See document of LimpidLog for details about how to use LimpidLog.
In your application
Log for auditing is part of your business logic. You need to hard-code log statement. This is different from LimpidLog which does not need hard-coded log statement.
You need import the AuditLog class:
import auditlog.AuditLog;
Then call the log method:
public static void log(int level, String where, String why, String message)
where:
The method is already initialized. No other preparation needed, just simply call the method.
The configuration options are:
Threshold: Command AuditLog.setThreshold will set new threshold dynamically. If the level of a call to AuditLog is equal or greater than threshold, the call will log a record.
For idle AuditLog, there is no speed penalty. The memory it takes is about 5K (very small).
For each method call to AuditLog, the time spend is very similar than other traditional logging system.
AuditLog is thread safe.
AuditLog records data thread-safely. Your application can run in multi-threading environment.
AuditLog manages run time configuration safely. But this issue is not relevant. There should be one person working on the configuration at the same time. If there are more than one person reconfigure the system, there will be logical conflicts: one wants to register a class, the other wants to de-register that class. AuditLog is not a consumer product. When logging is needed, there should be only one person from the response team to work on at a time.
AuditLog can be dynamically, programmatically reconfigured at runtime. AuditLog uses LimpidLog's method to configure. It is very simple. Just call the method:
public Object sendCommand(String action, Object argument) throws Exception {
For example,
new com.acelet.opensource.limpidlog.ClientTalk("localhost", 9876).sendCommand("AuditLog.setThreshold", "5");
See the following source code files for details: