Community
Participate
Working Groups
Build Identifier: 20100218-1602 If a plugin defines a view perspectiveExtension targeted at a perspective from another plugin, and the view is disabled by means of an activityPatternBinding with a core expression, the UI will try to create the view event though it is disabled, resulting in an exception. The exception only appears in the log. Heres my analysis: - PageLayout#createView(String partID) calls ViewRegistry#find(String id). - That method returns null because WorkbenchActivityHelper#restrictUseOf(desc)is true. - PageLayout#createView passes the null result to WorkbenchActivityHelper#filterItem, which returns false! - therefore LayoutHelper#createView is called, resulting in an exception Reproducible: Always Steps to Reproduce: 1. define a perspectiveExtension that adds a view to another plugins's perspective 2. add an activity with a regex expression, e.g. "com\.mycompany\.demo/..* 3. disable the activity 4. reset the perspective
I have to correct myself: the problem appears when the activity is enabled/disabled through an <enabledWhen> subelement in plugin.xml. Only in that case, the WorkbenchActivityHelper#restrictUseOf mtethod returns true, leading to the described phenomenon
the essence of the problem seems to be that enablement of activities through core expressions (i.e., in plugin.xml) does not work well
Created attachment 186220 [details] null guard v01 Suggested fix: If a view descriptor is not returned, that view doesn't exist. We can count it as filtered. PW
Created attachment 186296 [details] null guard v02 Provides more accurate behaviour. if the view is restricted, it returns. If the view is null because it is not defined, it still writes out the error. PW
Released to HEAD PW
In I20110124-1800 PW
