The next major release of the Pentaho Platform will include significant enhancements to OSGI support. Many of these features are in active development and may or may not make it in the next release. Those that do make it in may be modified from how they're described here.
The enhancements to the OSGI environment break down into several areas:
The Felix OSGI environment that shipped with 5.1 has been replaced by Apache Karaf. Karaf is a full application framework built on-top of the bare OSGI runtime. I provides such services as Hot Deployment, Provisioning, Runtime Configuration changes, remote SSH access and JMX integration. We have a slightly customized Karaf assembly deployed within the BA and DI Servers as well as within the PDI-OSGI-Bridge (described later). Documentation for the Karaf Assembly is located at Apache Karaf environment and Assembly
Karaf provisions bundles through logical collections called Features. Pentaho has created many features for the 6.0 development work. You can browse short summaries of the features here: Pentaho's Apache Karaf Features
6.0 ships with the PDI-OSGI-Bridge plugin in both the client and server environments. It enables the development of PDI plugins from within OSGI. Details of how to take advantage of the bridge are located here: OSGI in Kettle. All new PDI plugins will be developed as OSGI Bundles and many of the existing ones will be converted in future releases.
Components registered with the Pentaho System are now registered with the OSGI Service Registry. This completes the seamless migration of service objects between the Platform and OSGI's Service Registry.
The Karaf environment supplies many features which have been integrated with the server. Authentication into the Karaf container is done using Spring Security. The HTTP Servlet environment exposed to OSGI is bridged out to the Application Server (Tomcat). Other systems have been ported or re-written within the OSGI environments such as RequireJS, Localization and Configuration. Most of these are detailed below.
Most of the new features for 6.0 are being developed within the OSGI environment. These include Data Profiling, Monitoring, Lineage and the PDI-JDBC driver. In addition several foundational systems have been developed to support this new work including the RequireJS Manager, Internationalization and WebJars support.
We’re using the Apache Felix Bridge to expose Tomcat as the HttpService implementation within OSGI. HttpService is what allows bundles to register Servlets, Resources, etc. (http://www.osgi.org/javadoc/r4v42/org/osgi/service/http/HttpService.html)
The HttpService mount point is WEB_APP/osgi such that a servlet registered with the path “foo” will be available at localhost:8080/pentaho/osgi/foo.
Note: /osgi will likely change before final release.
Resources and Servlets can be registered by any valid OSGI service registration mechanism (Plain API, iPOJO, Dependency Services, Dependency Manager, Blueprint), we’re using Blueprint beans files with our work (http://www.ibm.com/developerworks/library/os-osgiblueprint/). Below are some example registration snippets:
<service interface="org.ops4j.pax.web.extender.whiteboard.ResourceMapping" >
<bean class="org.ops4j.pax.web.extender.whiteboard.runtime.DefaultResourceMapping">
<property name="alias" value="/snmp" /> <!-- http path -->
<property name="path" value="/res" /> <!--Local Folder within jar -->
</bean>
</service>
|
<service interface="javax.servlet.http.HttpServlet">
<service-properties>
<entry key="alias" value="/requirejs-manager/js/require-init.js"/>
</service-properties>
<bean class="org.pentaho.js.require.RequireJsConfigServlet">
<property name="manager" ref="configManager"/>
</bean>
</service>
|
The Karaf container embedded in Spoon uses a Jetty instance provided by PAX-WEB which provides more capabilities than are available with the standard HttpService (https://ops4j1.jira.com/wiki/display/paxweb/Pax+Web). PAX-WEB allows you to register filters, JSPs, Listeners, Error Pages. Basically it supports the entire servlet spec. Indeed you can even deploy WARs inside Karaf and they’ll be deployed by PAX-WEB.
The Karaf environment is configured with Apache CXF to support registration of services from bundles (http://cxf.apache.org). CXF supports SOAP services as well, but we should be REST where possible.
Example Blueprint JAX-RS Service Registration:
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
<bean id="serviceBean" class="pentaho.snmp.SnmpConsumer"/>
<jaxrs:server id="snmpService" address="/snmp">
<jaxrs:providers>
<bean class="org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider"/>
</jaxrs:providers>
<jaxrs:serviceBeans>
<ref component-id="serviceBean" />
<!-- more refs would go here -->
</jaxrs:serviceBeans>
</jaxrs:server>
|
The service above would be available at http://localhost:8080/pentaho/osgi/cxf/snmp
Note: the /osgi and /cxf path parts will likely change before final release.
We have a replacement for the platform-plugin-based RequireJS system available to bundles.
HTML pages include the following script tag which injects the RequireJS configuration and RequireJS itself.
<script type="text/javascript" src=" osgi/requirejs-manager/js/require-init.js"></script> |
Bundles contribute RequireJS configurations by having a
“META-INF/js/require.json” file in the bundle. The contents should be a valid RequireJS config:
{
"paths": {
"snmp": "snmp/snmpController"
}
“shims”: {}
}
|
The RequireJS config system is dynamic. The configuration updates as bundles are added/removed from the system.
We also support deploying WebJars into the Karaf container (http://www.webjars.org). They’ll be automatically transformed into bundles with the expected require.json defined previously. Webjars can be dropped into the /deploy directory or included in features using the pentaho-webjars: protocol
pentaho-webjars:file:/Users/johnson/foo.jar (filesystem) pentaho-webjars:mvn:pentaho/common-ui/1.0 (maven) |
Adding a dependency on a WebJar to a feature looks like the following:
<feature name="my-feature>
...
<bundle>pentaho-webjars:mvn:pentaho/common-ui/1.0</bundle>
</feature>
|
We have a centralized Internationalization service which has both server-side (java) and REST access. The implementation isn’t yet complete, but will eventually replace the fragmented systems in placed currently.