Bug 356469

Description Alain Le Guennec 2011-09-01 09:00:17 EDT

Many Papyrus command handlers trigger NullPointerExceptions during part deactivation (CopyHandler, RenameNamedElementHandler, etc...) if the new part being activated is not a papyrus-related part.

The cause is the way that the isEnabled() function is commonly implemented in Papyrus' command handlers.

Normally, the enablement state is supposed to be computed during setEnabled(evaluationContext), and then simply returned in isEnabled() (in such case, isEnabled() has no side-effect).
It turns out that Papyrus does not usually do this pre-computation of the enablement conditions in setEnabled(), and instead do all the hard work in isEnabled() on-the-fly.

It turns out that during part-deactivation, Eclipse retrieves the enablement state of the "old" handler before it gets replaced (not sure if it is that usefull, but it's done anyway), causing Papyrus to do the isEnabled() work again but in the unintended new context (see Command.setHandler()).
If the new part is not related to Papyrus, Papyrus has trouble getting to its service registry, among possible pbs. And the code in isEnabled() is often not prepare to cope with such situations, missing checks for null pointers for instance.

There are two ways to fix the problems:
-Make the code for isEnabled() more robust
-Preferably, redesign all Command Handlers to override setEnabled(evaluationContext), which would then build and cache the associated Papyrus command and check its executability.
All subclasses of org.eclipse.papyrus.modelexplorer.handler.AbstractCommandHandler and org.eclipse.papyrus.uml.menu.handler.AbstractEMFCommandHandler are potentially impacted.