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

Bug 348827

Summary:	Favorites relying on a Preferences race condition
Product:	[ECD] Orion	Reporter:	Simon Kaegi <simon_kaegi>
Component:	Client	Assignee:	Simon Kaegi <simon_kaegi>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Simon Kaegi

2011-06-08 23:10:06 EDT

Favorites was relying on a setTimeout in Preferences to delay the init call in PreferencesService and give it a chance to add an event listener before the init call dispatched the favorites changed event. Favorites should instead be both getting all the favorites and adding itself as a listener.

Comment 1 Simon Kaegi

2011-06-08 23:38:41 EDT

Fixed in HEAD. Susan reviewed.

Comment 2 Susan McCourt

2011-06-08 23:41:36 EDT

+1.  If this were an eclipse RC1 I would say it's unnecessary but we are being much wilder than this.  This is the kind of bug that gets noticed and may never get fixed in the course of release end game and is too boring a bug to fix when adding new stuff at the beginning of a release.  So I say fix it while we are here.

FWIW, originally when the services managed their own listeners (pre service registry), Boris and I talked about the old eclipse pattern where you have to:
- get something
- add a listener for it

and thought it might be cool to have the listener always fire the event when it gets a new listener.  Sort of like dependency injection.  We were trying to avoid duplicating the "get and listen" pattern all over the place.

When services moved to the service registry, I can remember wondering why this still worked.  Simon told me he had to add a hack to keep from breaking favorites.

So I think this proves that the "free get when you add a listener" is not a good idea and just causes confusion.