|
| |Home | Products | Documents | Downloads | Purchase | Support | Company | Partners | Contact | |
FAQ For LimpidLog
General
Can I use other log mechanisms, such as Log4J and JDK logging, with LimpidLog?
Can I redirect log records from LimpidLog to JDK logging or Log4J device?
The J2EE server or stand-alone application needs to start with LimpidLog. Is this a must?
I get an error: Unrecognized option: -javaagent:c:\a\o\build\limpidlogXXX.jar. What is wrong?
Line number events are recorded, but there is no local variable information. Why?
If you do not specify logProxy property, the default LogProxy will be file. The log files will be on your working directory. The file name is limpidlogXXXXXXXXXXXXXX.log, where XXXXXXXXXXXXXX is the time stamp when the file is created. Example: limpidlog20071216134332.log.
How to use LimpidLog in a production environment?
For a production environment, you may or may not ever encounter a bug. But if you want to have an opportunity to use LimpidLog when needed, you need to run your application with -javaagent option, to make it LimpidLog-enabled.
Or, when you need LimpidLog, restart your application server (for J2EE application) or application (for standalone application). If your application is running in a cluster, you can restart one node of the cluster and use LimpidLog for that server only.
You do not need anything special when you code your application, nor deploy your application.
Can I use other log mechanisms, such as Log4J and JDK logging, with LimpidLog?
You can. If you want, you can disable your existing logging by setting high threshold and use LimpidLog.
LimpidLog does not have any relationship with other loggings.
Can I redirect log records from LimpidLog to JDK logging or Log4J device?
The LogProxy for JDK logging or Log4J has not been implemented. Do you want to be a contributor or partner to do that?
The J2EE server or stand-alone application needs to start with LimpidLog. Is this a must?
The current implementation of Java requires to load javaagent at start time.
When my class will be reloaded?
The class you explicitly register will be redefined and reloaded at the time you register, if it has been loaded already. If the class has not been loaded, there will be no reloading. The class will be freshly loaded with sidenoting when it is needed by JVM. The class will be redefined using original definition and reloaded when you deregister it.
I get an error: Unrecognized option: -javaagent:c:\a\o\build\limpidlogXXX.jar. What is wrong?
Your Java version is younger that 1.5 (Java 5).
Will LimpidLog support Java 1.3 or 1.4?
LimpidLog uses java.lang.instrument to redefine classes.
java.lang.instrument is available for Java 1.5 only. This cry should go to Java.
JRocket 1.4 implements similar package like java.lang.instrument. LimpidLog will
try that later.
You can use Java 1.5 to run your application. Java 1.5 is backward compatible.
To debug LimpidLog, you need to give an option for -javaagent, like:
-javaagent:limpidlog100.jar=debug=true
You should see debug information immediately:
LimpidLog 1.10 from Acelet. LGPL license. ASM 2.2.3 from ObjectWeb.
Listening on port: 9876
Depot.retrieveOptions≡[DEBUG]≡Listening on port=9876
Depot.retrieveOptions≡[DEBUG]≡properties={debug=true}
Depot.retrieveOptions≡[DEBUG]≡LogProxy: null
Depot.retrieveOptions≡[DEBUG]≡System properties >>>>>{java.runtime.name=Java(TM)
2 Runtime Environme
...
If you do not see above information, the LimpidLog has not started yet.
When everything is okay, you do not need logging. In that case, LimpidLog is idle. The performance price is almost nothing: When some thing is wrong, you want to debug, you need logging. You dynamically re-configure it. Then the performance price is higher than other logging: LimpidLog logs more information than other logging. But the performance price is only for the registered classes. You probably know which classes may have problems. The logging for unregistered classes is still idle and no performance price. So the overall price should be lower than other logging.The performance price occurs only for registered classes, and only when you want to log at run time. For Log4J or JDK logging, if you can not dynamically reconfigure them, you pay performance price all the time, even there is no issues. In that case, your log files are liability, not asset.
Line number events are recorded, but there is no local variable information. Why?
Your application was not compiled use -g option. There is not enough debug information in your class file. For LimpidDebugger, the more debug information the better.