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

Bug 323393

Summary:	[Contributions] Service initialization wrong! Sources must be initialized before Handlers
Product:	[Eclipse Project] Platform	Reporter:	Paul Webster <pwebster>
Component:	UI	Assignee:	Paul Webster <pwebster>
Status:	VERIFIED FIXED	QA Contact:
Severity:	major
Priority:	P3	CC:	bokowski, prakash, remy.suen, tonny.madsen
Version:	3.6
Target Milestone:	3.7 M4
Hardware:	PC
OS:	Windows Vista
Whiteboard:
Bug Depends on:	316701
Bug Blocks:

Description Paul Webster

2010-08-23 10:42:02 EDT

+++ This bug was initially created as a clone of Bug #316701 +++

The initialization of services in the Workbench has been reworked in in 3.6 compared with 3.5

Unfortunately source providers (initialized in Workbench.startSourceProviders()) are now initialized *after* handlers (in Workbench.initializeDefaultServices()).

The result is that a handler with an activeWhen expression which refers to a source variable _other_ that the built-in variables from SourcePriorityNameMapping, will get source priority 0 - same as if it does not have an expression. Which is wrong, if the used variables have priorities installed via the extension point org.eclipse.ui.services/sourceProvider/variable.

This is a blocking issues for RCP applications, as far as I can see, as later execution of the command results in no active handler!

I cannot say, why the change was made between 3.5 and 3.6 - quite deliberate as seen from comments in workbench.java - so I cannot guess on a fix...

-- Configuration Details --
Product: Eclipse 1.3.0.20100526-1137 (org.eclipse.epp.package.rcp.product)
Installed Features:
 org.eclipse.platform 3.6.0.v20100527-9gF78GpqFt6trOGhCMC-p4sxjlLvz0FU_i

Comment 1 Tonny Madsen

2010-08-23 11:03:44 EDT

I suppose this bug is here because you want to clean up the code in the workbench initialization for 3.7?

Comment 2 Paul Webster

2010-08-23 11:05:09 EDT

(In reply to comment #1)
> I suppose this bug is here because you want to clean up the code in the
> workbench initialization for 3.7?

I need to fix it in 3.7 as well.

PW

Comment 3 Tonny Madsen

2010-08-23 11:10:18 EDT

(In reply to comment #2)
> (In reply to comment #1)
> > I suppose this bug is here because you want to clean up the code in the
> > workbench initialization for 3.7?
> 
> I need to fix it in 3.7 as well.
> 
> PW

A bit off topic for this bug... but, how come you need a new bug entry for 3.7?

Comment 4 Remy Suen

2010-08-23 11:23:54 EDT

(In reply to comment #3)
> A bit off topic for this bug... but, how come you need a new bug entry for 3.7?

One of the reasons we do this is so that we can mark the individual bug as being verified during its corresponding verification pass. The build we verify 3.6.1 bugs is not the same build we verify 3.7 bugs (naturally). Likewise, the time we do this is rarely on the same day.

Verifying two separate streams on the same bug makes queries obsolete (based on "Target Milestone" field).

Does that answer your question, Tonny?

Comment 5 Paul Webster

2010-11-09 12:00:19 EST

Released attachment 171840 [details] to HEAD
PW

Comment 6 Paul Webster

2010-12-07 14:09:03 EST

In I20101206-1800
PW