Community
Participate
Working Groups
Build Identifier: M20080911-1700 this bug is related to "Bug 87504 - Log size limits and rotating logs" this bug is found in our 3.4 eclipse osgi environment. but should be a common bug and still exist on even latest eclipse codes. the bug is about that for special eclipse application with , there is no workspace. And all log will be in the configuration directory. while in the configuration directory, the format of the log file is <timestamp>.log . it is not the .log file format. in bug 87504, the endless log file in workspace is solved, and "eclipse.log.size.max" and "eclipse.log.backup.max" can be used to limit the overall log size. and it applies some how to configuration logs, but not all. because it can only limit one time generated log file number and size, but not the overall log files in the configuration dir. (because each time used log file name is differnt) I will attached a example picture of what i mean. in this real example, the overall log file extends to quite big. since they are used many times. (see the log files created time.) Reproducible: Always Steps to Reproduce: hard to reproduce , since need a special osgi application . but easy to understand. Pleasae read the details part
Created attachment 207698 [details] logsInConfigurationDir this picture shows part of hte log files in the configuration directory. currently, i can only limit the one time (eclipse application run) log files. (default is 10), but can not limit the overall log files. since it can be used day by day. and can grow endlessly.
My proposal for this this problem is to introduce another configuration to specify the log file name format for logs in the configuration dir. for example it can be named as "eclipse.log.configurationlog.simplename" (or a better naming?) by default(or not set) it is false. Only if it is manulaly set to "true", then the naming will not be <timestamp>.log for configuration logs,but change to .log to be the same as workspace log file naming format. Such change can be done in EclipseLog class and will not affect all exsiting users.
Thanks we will investigate.
We already have an option (osgi.logfile) that allows you to specify a fully qualified path to a file where you want us to log. It is unfortunate that it expects this to be fully qualified. One option is to enhance this option to allow unqualified names (i.e. mylog) that will then be placed directly under the configuration folder. I am willing to consider that enhancement. But there is another option for you to control this today. You could get the org.eclipse.osgi.framework.log.FrameworkLog service yourself and call org.eclipse.osgi.framework.log.FrameworkLog.setFile(File, boolean). This is what happens in the IDE when the workspace is chosen. The workbench calls this method to tell the FrameworkLog to switch to another log file and it should copy the content from the initial log file and delete the initial <timestame>.log file. Will that option work for you?
Since there is a workaround to this issue, I am moving the enhancement to kepler.
about the workaround: "org.eclipse.osgi.framework.log.FrameworkLog service yourself and call org.eclipse.osgi.framework.log.FrameworkLog.setFile(File, boolean)." where can i call this method? we may need to write a special startup extention or apply it in our each Activator... Both of the above ways is not good. OR is there a speical extention point to set the file, seems not. We will wait for the fix, better to introduce some configuration item or extention point. Then patch back to our used eclipse version by ourself.
(In reply to comment #6) > about the workaround: > "org.eclipse.osgi.framework.log.FrameworkLog service yourself and call > org.eclipse.osgi.framework.log.FrameworkLog.setFile(File, boolean)." > > where can i call this method? we may need to write a special startup extention > or apply it in our each Activator... > Both of the above ways is not good. > OR is there a speical extention point to set the file, seems not. You can call this method any time actually. You mention a special eclipse application. I assume there is some entry point to your application during startup where you can call the FrameworkLog.setFile method. It should not matter if this is called before or after the first log entry is written since it will move any existing content over to the new location (if you use the append option). > > We will wait for the fix, better to introduce some configuration item or > extention point. Then patch back to our used eclipse version by ourself. I would be interested if the above option works because it involves no patching of older versions of eclipse.
thanks for your comments, Thomas. I will try.
I released changes to support relative paths for the osgi.logfile as described in comment 4: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=1cb7a9514ecb5934a4e2d3c6320bde13c11afb19
