Spring OSGi - Building extensible and customizable bundles

(work in progess)

Abstract

This artcile shows how to build a domain specific Spring OSGi bundle (dynamic module), which can be customized in projects using fragment bundles. Of course one can use the RCP extension points conecpt etc. to provide customization and extensibility, but in my opinion the Spring way is much more convenient, powerful and dynamic.

The following ideas could be used to inspire a product like application based on a lightweight RCP application framework, wich can be customized and extended in projects to customer needs.

Example case

A bundle provides a view showing data columns of a database table. A project has the requirement to change the columns to be displayed and to change behavior of the view components itself. The view itself is a Spring bean. Lets have a look to the MANIFEST.MF of the host bundle providing the standard view and behavior.

Architecture fundamentals

The following sub chapters describe briefly the fundamental parts of the architecture for dynamic extensible Spring OSGi bundles.

The MANIFEST.MF - Spring application context loading

Manifest-Version: 1.0
Unversioned-Imports: *
Bundle-Name: acme.bundle
Bundle-Vendor: acme
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: acme.CommonFrameWorkBundleActivator
Spring-Context: META-INF/spring/*-init.xml,
META-INF/spring/*.xml,
META-INF/spring-ext/*-init.xml,
META-INF/spring-ext/*.xml

Important is the value of Spring-Context. It defines the order in which the Spring OSGi framework loads the configuration files.

1. META-INF/spring/*-init.xml - this file is loaded first. Put any bootstrap beans here
2. META-INF/spring/*.xml - all remaining xml files in META-INF/spring/ are loaded
3. now META-INF/spring-ext/*-init.xml is loaded. This file is not provided by the host bundle, but later by the fragment bundle, which extends the host bundle
4. META-INF/spring-ext/*.xml - all other xml files of the fragment are loaded

Bundle Activator

Spring BeanPostProcessors

Spring xml schema extensions

Eclipse RCP - Hide minimize / maximize buttons for editors and views

Abstract

Sometimes a user should not be allowed to maximize/minimize a view or editor. This article is about how achieve this.

Defining custom PresentationFactory

The main entry point to change the presentation of RCP editors and views is to define a custom PresentationFactory, which extends the the default presenetation factory. This presenetation factory then needs to be registered in the plugin.xml.

Registering custom presentation factory in plugin.xml

<extension point="org.eclipse.ui.presentationFactories">
  <factory class="org.acme.ExampleWorkbenchPresentationFactory"/>
</extension>

Changing editor presentation

In order to chage the editor presentation - here to hide the minmize / maximize buttons - we need to override the createEditorPresentation method in the presentation factory

@Override
public StackPresentation createEditorPresentation(final Composite parent,
        final IStackPresentationSite site) {
    final TabbedStackPresentation presentation = (TabbedStackPresentation)super.createViewPresentation(parent, site);
        
    presentation.showMinMax(false);
       
    return presentation;
}

The interesting code here is presentation.showMinMax(false).

Changing view presentation

It is the same code as for the editors - we need to override the method createViewPresentation in the presentation factory.

Using fixed layout

The above steps show, how to hide the minimize and maximize buttons of editors and views, but a double click on an editor/view will still cause the editor/view to be maximized. In order to avoid that, an implemenation of the interface IPerspectiveFactory should be provided as follows

public class MyPerspectiveFactory implements IPerspectiveFactory {
    @Override
    public void createInitialLayout(final IPageLayout layout) {
        layout.setFixed(isLayoutFixed());
    }
}