Hitachi Vantara Pentaho Community Wiki
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Platform migration to OSGI


For some years now it’s been our desire to transition away from our limited home-grown plugin system to an industry standard modular system based-on OSGI. In 5.0 we began laying the groundwork for this transition. 5.1 sees us forge a clear migration path and rolls-out the first stages of OSGI in the Platform.


Why is this migration necessary? The answer requires a little background on the architecture of the Platform.

The Platform at one time was designed around a central service-locator backed by a singular ObjectFactory ( Spring in production ). Unfortunately this service locator didn’t support collections of objects, querying, or the ability to extend it without editing a bunch of core files. There was no clean way to drop something into the platform and have it integrate well with the system. Consequently the IPluginManager came to prominence. IPluginManager and PlatformPlugins provided a good “vehicle” for getting new features into the system. Since then the Platform has steadily moved to a more plugin-centric model. This has been a double-edged sword. One one side the extensibility of the Platform without having the modify the core increased greatly. On the other, "core" code became a second-class citizen in it’s own house. To work around this many of the "core" features had to be registered through placeholder plugins such as the “default-plugin” and "admin-plugin".

We also increasingly find ourselves running into the limitations of the Platform Plugin system. Classes cannot be shared between plugins, limiting the extension of the platform and hurting cohesion between plugins. As Classes cannot be shared , no new concepts can be added to the system. Calls between plugins are diffucult to perform, often relying using web services, content-generators and even reflection to work-around this limitation.


OSGI is a industry-standard Modular Software framework. It's design supersedes that of a plugin architecture. Core code and extensions are built using the same modular design, Bundles, which most closely resemble the concept of Plugins. Everything is on the same footing in OSGI. Versionsed Classes can be freely shared between bundles allowing for the controlled extension of the platform. The OSGI environment has built-in resilience to change at runtime for bundles installing and uninstalling.

In truth the Migration to OSGI is not exchanging one plugin system to another. Rather it is moving to an architecture which does not require a Plugin system at all.

5.0 and 5.1 Enhancements preparing for OSGI

You can read about the steps taken to in 5.0 and 5.1 which set the stage for this migration here:
Platform enhancements in 5.0 and 5.1

5.2 and Beyond -the next steps

The goal for 5.2 is to be able to migrate PlatformPlugins to Bundles. Several Jira cases have been created to encapsulate the work to be done in 5.2

BISERVER-11539 - Support the ability to provide Platform Plugins from OSGI
Our home-grown plugin system is limiting our ability to deliver compelling product…

BISERVER-11540 - Deprecate the IPluginManager as a Service Locator
Have the PluginManager register objects with PentahoSystem instead so we have a single point for service location.

BISERVER-11541 - IPluginResourceLoader needs to be modified to work with resources provided by OSGI Bundles
The ResourceLoader api is separate from PlatformPlugins and The IPluginManager but one that needs to be made to work with OSGI Bundles.

[MARKET-151 - The Marketplace needs to be updated to work with OSGI Bundle plugins|

BISERVER-11542 - Sample OSGI Bundles need to be written demonstrating PlatformPlugin-like behavior

BISERVER-11543 - A Type-Tracking system needs to be added to the Pentaho Platform API
As the new system allows PlatformPlugins and OSGI Bundles to be de/registered at runtime, we need a way to notify other areas of the system of the events.

BISERVER-11544 - PentahoSystem's AggregateObjectFactory needs to be updated to cache query results
Currently PentahoSystem.getXXX calls are not cached and query the underlying ObjectFactory implementations with every call. This can become extremely inefficient as the System grows.

BISERVER-11545 - The Pentaho Spring Extensions need to be updated for Spring 3.2.5 so they can be used within OSGI Bundle Blueprint files

  • No labels