It has not been too long ago when any new vSphere Client release, major or minor, required changes to every plugin in the ecosystem. This is always associated with extra work to cover unplanned requirements on all sides of the spectrum: the customers, the partners and VMware as platform provider.

It is important to have a look at the big picture, summarize and categorize past breakages, analyze the reasons and see where plugins are heading: to a dead end, bumpy road or the highway.

In this first part of the series on plugin stability we will focus on the overview of known plugin failures with the vSphere Client (HTML) and the deprecated vSphere Web Client (Flash).

Note: The term “vSphere Client” is used to indicate any of the two web clients while the desktop client is not considered.

Broken backward compatibility of APIs

Let’s focus first on the situations where changes have been required by vSphere Client plugin vendors to preserve compatibility with new vSphere Client versions.

The following is an overview of all known API backward compatibility breakages.

Common plugin-side / user-side issues

1. Plugin registration and downloading errors. The only valid way to introduce a plugin in the environment is by registering it as a vCenter extension with all vCenter Servers it should operate on. A plugin will not be available in the vSphere Client if:
   • it was not registered
   • it was registered with a wrong URL
   • it was registered with a correct URL but no/wrong server thumbprint
2. Version compatibility errors
   • Plugin does not claim support for the current Client version.
   • Plugin is blacklisted in the Client’s compatibility-matrix.xml (e.g. a master admin might disable it for the whole environment if it is known to misbehave).
3. Interoperability failures of one plugin against the Client or another plugin.
   • Usage of not recommended OSGi practices by one of the plugins (e.g. dynamic imports, not specifying version range of imported packages, etc.).
   • Plugin clashing – when a plugin incorrectly wires against an existing version of a dependent OSGi package delivered by another plugin or the Client. A classic example is the usage of vim25 and vi-java OSGi libraries both of which export the same com.vmware.vim25 package.
   • Delivering another version of Spring. As the Client itself is based on Spring at it’s core the Spring version is enforced.
   • Multiple plugin iframes (e.g. on Summary pages) use common underlying objects which may result in mutation by one plugin impacting another plugin.
4. Using undocumented and unsupported features exposed to plugins through the plugin manifest. As the vSphere Client itself is built around the same extensibility framework there are features which are supposed to be used only internally and provide no backward compatibility guarantees.

vSphere Client bugs impacting plugins

These include bugs not requiring plugin changes but only fixes in the Client.

1. [6.7, 6.7U1) Localization of HTML plugins does not fallback to English US when the current locale is not supported by the plugin or when it is not a full language tag (e.g. en instead of en-US).
2. [6.5U1, 6.7U1) Sub-menus and separators are ignored in plugin-defined menus.
3. [6.5, 6.7U1) Localization of HTML plugin labels is sporadically broken after first plugin deployment.
4. [6.5, 6.7U1) Concurrency bug leading to data request failures and getUserSession Java API returning null.
5. [6.5U1, 6.7U1) Usage of <privilege> tag to filter out global extensions is ignored or leads to discarding of the extension regardless of the actual user privilege value.
6. [6.0U2, 6.7U1] Flex plugin portlets throw errors if Global refresh is the first action after opening a Summary page.
7. [5.5U1, 6.5U1) Modal dialogs are cuts off on small screens and cancel action results in errors.
8. [5.5U1, 6.0U1) sendNavigationRequest Bridge API stops working when target object was not previously displayed in an HTML view.

Misbehaving plugins impacting vSphere Client

These are usually login and performance problems caused by plugins:

1. All plugins being downloaded at login time might slow down or fail the vSphere Client login.
2. Plugins which do extension filtering based on custom user privileges or properties take longer to evaluate which results in slow loading of the whole UI screen that hosts the plugin extensions (delaying not only those extensions but the overall usability of the vSphere Client).

This has been the summary of the most important known problems in the vSphere Client plugin ecosystem. If you face a common problem you don’t see in the list please comment below. Sharing the war stories from your experience is always appreciated.

In the next part of the series we will analyze the past instability from an architectural and design but also from purely practical perspective.