Eclipse 4 RCP HandlerProcessingAddon启动顺序问题咨询

Hey there, let's break down what's going on with your E4 application's startup behavior and how to address it.

Why the Startup Order Changed #

The key culprit here is how E4 processes handlers contributed via the application model:

• When E4Application.createE4Workbench() runs (triggered by your PlatformUI.createAndRunWorkbench() call), it parses the entire E4 application model early on. This includes scanning all handlers defined in your plugins' .e4xmi files.
• To resolve and prepare these handler classes for use, OSGi will activate their hosting plugins immediately—even before the splash screen's progress bar appears. This bypasses the usual gradual plugin activation that the progress bar would track.
• Once most plugins are already loaded before the progress bar is visible, there's almost nothing left for it to track, so it zips through completion quickly.

Fixes to Try #

Here are practical steps to adjust the behavior back to what you expect:

1. Use Lazy Activation for Handler Plugins

If your handlers don't need to be ready the second the app starts (e.g., they only run when a user triggers a command), enable lazy activation for their plugins:

• Open the plugin's MANIFEST.MF
• Add or update the line: Bundle-ActivationPolicy: lazy
• This tells OSGi to only activate the plugin when the handler is first invoked, rather than during application model parsing.

Note: Skip this if your handler relies on services that must initialize during startup.

2. Adjust Application Model Parsing Timing

You can customize when E4 parses the handler contributions by extending E4Application:

• Create a subclass of E4Application
• Override createE4Workbench() to delay parsing the model's handler elements until after the splash screen's progress bar is visible.
• This requires digging into E4's internal initialization flow, so be sure to test thoroughly to avoid breaking other core setup steps.

3. Update the Splash Screen Progress Tracking

If early plugin activation is unavoidable (e.g., some handlers need to be ready at startup), modify the splash screen to track the actual work happening:

• Use an E4 Addon or extend the org.eclipse.ui.startup extension point to add custom progress updates.
• Track steps like application model parsing, handler initialization, and service setup, then push those updates to the splash screen's progress bar. This gives users meaningful feedback instead of a fast, empty progress bar.

4. Optimize Handler Dependencies

Sometimes handlers pull in a chain of unexpected dependencies that trigger early plugin activation:

• Use Eclipse's Bundle Explorer or OSGi console commands like ss (show bundles) and diag (diagnose dependencies) to map out which plugins are being activated early.
• Remove unnecessary dependencies from your handler classes, or switch to dynamic service references (using @Reference(policy = ReferencePolicy.DYNAMIC)) to avoid triggering immediate activation.

Quick Recap on PlatformUI.createAndRunWorkbench() #

Just to connect the dots: this method initializes the classic Eclipse UI layer first, then hands off to E4's workbench creation. When E4 processes the application model, it needs to resolve all handler classes to ensure they're ready for command execution—this is what's driving the early plugin activation you're seeing.

内容的提问来源于stack exchange，提问作者bunion92