With the changes from commit f638d309e065aa92f1b3616728e174b5ed7c4488 we
may run into endless loop if the IPropertyChangeListener installed on
AbstractWorkingSetManager trigger working set API's during working set
restore operation.
The recursion is possible because the current working set design has a
major flaw - it allows events to be triggered on not yet fully created
working sets (see bug 479217).
The recursion is possible via this call stack:
WorkingSet.restoreWorkingSet(WorkingSet.java:151)
AbstractWorkingSet.getElementsArray(AbstractWorkingSet.java:166)
AbstractWorkingSet.isEmpty(AbstractWorkingSet.java:200)
BAD_CLIENT.propertyChange()
AbstractWorkingSetManager$5.run(AbstractWorkingSetManager.java:378)
AbstractWorkingSetManager.firePropertyChange(AbstractWorkingSetManager.java:391)
AbstractWorkingSetManager.getUpdater(AbstractWorkingSetManager.java:725)
WorkingSet.getUpdater(WorkingSet.java:314)
WorkingSet.restoreWorkingSet(WorkingSet.java:151)
To avoid the recursion on restore, we fix the getUpdater() so that it
remembers just created working set *before* sending an event to the
listeners. This way the next call to getUpdater() will return already
created instance, instead of creating new one, and recursion does not
occure.
Change-Id: Ibd2ce63dbf4497b403f83aa6a88a17747c18c629
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>