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

Introduction

The first two releases of version 5 Platform (5.0 and 5.1) include core enhancements designed for use today while setting the stage for larger things to come in future releases. 5.0 saw enhancements to PentahoSysten's ObjectFactory APIs as well as extending Spring's capabilities with Pentaho extensions which are detailed here: Pentaho ObjectFactory and Spring Enhancements. 5.1 builds upon this work as preparation for the Platform's migration to OSGI: Platform migration to OSGI. This preparation involves leveling the field between legacy plugins, core code and OSGI Bundles. Once on an equal footing, Platform Plugins can be migrated to OSGI Bundles over a period of time.

Leveling the field

Early-on we identified that the dual APIs of PentahoSystem.getXXX() and IPluginManager.getXXX needed to be consolidated. The choice was made to enhance the PentahoSystem's backing IPentahoObjectFactory APIs to support collections of objects per type (Class/Interface) as well as adding a filtering mechanism (find IContentGenerator for type 'prpt'). The combination of these two would allow for a transition away from the IPluginManager API. 5.0 delivered these enhancements.

Extensible ObjectFactory for PentahoSystem

5.0 also replaced the singular Spring-based IPentahoObjectFactory with an Aggregating ObjectFactory implementation. This new AggregateObjectFactory supports the registration of any number of IPentahoObjectFactory instances. Queries to the Aggregate call down to all configured "sub"-factories for matches. The results are filtered by any query conditions, ordered by priority and returned back. The AggregateObjectFactory can be thought of as a single Logical view over many Physicals underneath. The main Spring ApplicationContent (pentaho-spring-beans.xml) is registered as well as any plugin.spring.xml files publishing beans (link to 5.0 document). 5.1 sees two new sub-factories registered by default, RuntimeObjectFactory and OSGIObjectFactory

AggregateObjectFactory:

ObjectReferences

Another change made in the 5.0 release was the introduction of IPentahoObjectReference (source). These are wrappers, or more appropriately descriptors, for an Object available in the Pentaho System. The main advantage these bring is the ability to provide attribute metadata which powers the ordering and filtering capabilities. It also allows for the lazy creation of the actual objects described by the reference. The same lazy mechanism also makes it possible for an ObjectReference to be a factory.

5.1 Enhancements

5.1 sees the first usage of OSGI in the platform and the ability to register objects at runtime which powers a new IPluginManager implementation.

OSGI ObjectFactory

The OSGIObjectFactory inspects the Service Registry within the running OSGI instance to find matching ServiceReferences. If your bundle registers a Service, it can be found through PentahoSystem.getXXX calls by the same Classes/Interfaces and properties as it was registered with in OSGI.

Example Service Registration from an OSGI Bundle
BundleContext cxt = ...
IContentInfo infoInstance = new ContentInfo();
Hashtable props = new Hashtable(){{ put("prop1", "value"); }};
cxt.registerService( IContentInfo.class, infoInstance, props );
Querying in Pentaho Code
IContentInfo fromOsgi = PentahoSystem.get( IContentInfo.class, null, Collections.singletonMap( "prop1", "value" ) );

You can read more about OSGI usage in the 5.1 platform here OSGI in 5.1

Runtime ObjectFactory

The RuntimeObjectFactory is an implementation of the new IPentahoRegistrableObjectFactory interface (source). This interface extends the IPentahoObjectFactory with methods allowing the registration of Objects and IPentahoObjectReferences at runtime. Some built-in IPentahoObjectReference implementations are available for common factory scenarios ( SingletonPentahoObjectReference, SessionBoundPentahoObjectReference, PrototypePentahoObjectReference). Each of these has a static Builder available to make construction easier. You can find examples of how to use these new runtime registration features here: RuntimeObjectFactory Usage

EEPluginManager

The new EEPluginManager uses the RuntimeObjectFactory extensions to store plugin objects in the PentahoSystem instead of keeping them hidden within, as was done in the DefaultPluginManager. The result is that you no longer have to make calls to the IPluginManager and can instead query the PentahoSystem directly:

// instead of this
IPluginManager pluginManager = PentahoSystem.get( IPluginManager.class );
List<XulOverlay> overlays = pluginManager.getOverlays();

// you can call this
List<XulOverlay> overlays = PentahoSystem.getAll( XulOverlay.class )

The significance of this change is that this second call will return XulOverlays not just from the PlatformPlugins, but also from OSGI bundles, configured Spring ApplicationContexts or anyone registered with the AggregateObjectFactory.

Deprecation of the IPluginManager

All existing IPluginManager calls will continue to function for some time to come. They also gain the ability to find Objects registered from OSGI Bundles as described. However, we do encourage you to start migrating to PentahoSystem calls and away from the IPluginManager API as outlined here: Migrating away from IPluginManager calls

Final 5.1 Architecture:

  • No labels