Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365155

Summary:

logs in configuration dir grow endlessly

Product:

[Eclipse Project] Equinox

Reporter:

Ben Xu <xufengbing>

Component:

Framework

Assignee:

Thomas Watson <tjwatson>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

glyn.normington, tjwatson

Version:

3.4

Target Milestone:

Kepler M6

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
logsInConfigurationDir	none

Description Ben Xu

2011-11-29 22:01:10 EST

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

Comment 1 Ben Xu

2011-11-29 22:03:55 EST

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.

Comment 2 Ben Xu

2011-11-29 22:47:04 EST

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.

Comment 3 Thomas Watson

2011-11-30 10:00:33 EST

Thanks we will investigate.

Comment 4 Thomas Watson

2012-02-29 14:29:51 EST

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?

Comment 5 Thomas Watson

2012-04-30 12:00:18 EDT

Since there is a workaround to this issue, I am moving the enhancement to kepler.

Comment 6 Ben Xu

2012-05-02 02:30:55 EDT

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.

Comment 7 Thomas Watson

2012-05-02 14:58:39 EDT

(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.

Comment 8 Ben Xu

2012-05-03 04:02:18 EDT

thanks for your comments, Thomas. 
I will try.

Comment 9 Thomas Watson

2013-02-11 14:44:14 EST

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