Community
Participate
Working Groups
The WSAD service people have a requirement to maintain a full service log of all install/ update activities. For 2.0 we have set the default number of histories to 50, but this is not a good solution. We should simply write a flat log that we append activities to (not xml, similar to .log)
See bug 19301 for additional details
*** Bug 21363 has been marked as a duplicate of this bug. ***
Here is the log file spec: 1) The file should be called .install-log 2) The file should be written in the .config directory in the metadata. 3) Whenever a new configuration is pushed on top, the following entry should be appended: !CONFIGURATION <label> where <label> is the value returned from IInstallConfiguration.getLabel(). 4) Whenever a new activity is added to the current configuration, it should be appended to the file as follows: !ACTIVITY <date> <target> <action> <status> There should be a blank line between the last activity entry of the previous configuration and the configuration entry of the next configuration, as in: !ACTIVITY Sep 29, 2002 10:47:20 PM com.example.e388_1.0.0 feature-install success !CONFIGURATION Sep 29, 2002 10:55:08 PM !ACTIVITY Sep 29, 2002 10:55:15 PM com.example.root_1.0.1 configure success Activity fields: <date> is the date string as stored in IActivity object. <target> is the value return by IActivity.getLabel() <action> is one of: feature-install feature-remove site-install site-remove unconfigure configure revert reconciliation <status> is one of: success (for STATUS_OK from IActivity.getStatus()) failure (for STATUS_NOK from IActivity.getAStatus()) The file should be opened for writing only for the duration of the append, then immediately closed to release the handle. See PlatformLogWriter.java in org.eclipse.core.runtime plug-in for implementation ideas. We should duplicate behaviour, encoding, and error handling.
In the current model, due to implementation, activities are not added to the current configuration. They are added to a clone of the configuration. The clone is added as the current configuration. So activities will be logged when the new configuration is added as current configuraton... thoughts ?
When the new configuration is pushed on top of the stack as the new current configuration (or even better - when 'save' is called to preserve the configuration), you should append the log file with the configuration entry and all the activities. It is not important to immediately append the log for each event: what is important is to have an ever-growing log of all the install/update activities that can be sent to service/support in case of problems.
The log is created when the Configuration is saved, thus logging the exact same content as the configuration XML files. Test in integration build