Thursday, August 31, 2017

OSGi Bndtools

Bndtools is framework or set of libraries, which make OSGi bundle development very easy. It will automate some of the configurations and bundle dependencies resolution in the development. It will provide set of tasks and configuration, which makes OSGi developers life easy.

BND Tools provides the eclipse plugin so that we can install plugin in eclipse. BND tools also available for different build tools like MAVEN and Gradle.

The following are the main resources we can get more information about BND Tools



Image source from bndtools.org

The following are the different environment plugins that will provide Bndtools capabilities in the OSGi bundle development.

BND Plugin for Gradle

BND Plugin for Gradle is plugin, which provide BND capabilities in the Gradle build environment.


BND Plugin for MAVEN

BND Plugin also provides the maven plugin, which we can use in the MAVEN, based OSGi bundle development.


BND for ANT

BND also support ANT build environment. However, ANT already older one no longer use in the projects. So do not have much information.

BND Tools plugin for Eclipse IDE

BND capabilities also available in Eclipse IDE. We have BND tools plugin in the eclipse market place or we have plugin package file we can install in Eclipse IDE.


Apache Felix Maven Bundle Plugin

Apache Felix Maven Bundle Plugin is maven supported BND plugin, which will use in Apache Felix OSGi implementation bundle development.



Gradle OSGi Plugin

Gradle OSGi Plugin is Gradle plugin that come with Gradle build tool.


OSGi-Run Plugin

OSGi-Run Plugin is another implementation that available in Gradle. It will create and run the OSGi runtime.


Author

Tuesday, August 29, 2017

OSGi Dependency Management

OSGi is defining dynamic component development for JAVA. Complex application divided into multiple modules. These modules can communicate each other.  OSGi dependency management provide way to manage their dependencies among each other.

When we break the application into multiple bundles none of the classes or interfaces not available to other bundles until we do some configuration in the bundles. Dependency management define the way to share these classes between the bundles.

Before expose these classes or uses it in other bundles we have to define this information in the OSGi MANIFEST file with some specific headers.

We have mechanism called Export and Import in the OSGi and such way we can export one-bundle classes and we can use these exported classes in other bundle by using import mechanism.

We have following headers, which define the package level dependency in OSGi bundles and these headers need to define in the MENIFEST file.

Export-Package:  

We have to specify the package names with comma separated values, which we wanted to export such way it can be available to other bundles.

Example:


Export-Package: com.liferaysavvy.example.service, com.liferaysavvy.example.service1



 Import-Package:

Import package will use to user other bundle classes that already exported by the other bundles.

Example:


Export-Package: com.liferaysavvy.example.service, org.osgi.framework; version="1.3.0"



 OSGi have several other ways to manage their decencies between bundles. Such a way other classes are visible to the bundles.

The following are different ways.

Boot Classpath

It will define the basic classes and jar file required by the bundles or OSGi container. Example java.* package classes are available in the boot classpath level.

Framework Classpath

Its separate class loader and OSGi framework related classes and packages are available. Specially OSGi framework API and its implementation classes.

Bundle space

Bundle space consist of JAR file, which used by the bundle like dependency jar files, which are used current bundle only.

Imported packages

Imported packages will consist of specific classes imported by the bundles. Let us say bundles have many components but some of components wants to make visible to other bundles and these specific classes are available in Imported packages

In this case, we will use Import-Package header, which will make set of classes visible to other bundles.

There are many headers, which we can define in the OSGi bundle MENIFEST file. The following are the important headers, which are involved in the dependency management.

Export-Package:  

We have to specify the package names with comma separated values, which we wanted to export such way it can be available to other bundles.

Import-Package:

Import package will use to user other bundle classes that already exported by the other bundles.

Bundle-Classpath:

Bundle-ClassPath define list of comma separated jar files or directories which will used by the current bundle.

Export-Service

Export-Service Define specific services that make visible to other bundles.

Import-Service

What are the services exported by bundles can be used by other with Import-Service header.
There are other headers and each header have its own importance in the OSGi MANIFEST file. Get all header information from the following link


When we work with dependency management following are the steps. Usually we have at least two bundles to make work dependency management.

Bundle A

Define your services in the interface
Implement services for the defined interfaces
Add your services package path under Export-Package header in MANIFEST file
Register your Service implementation Object in “Bundle A” Activator class

Bundle B

Define exported package name under Import-Package header in MANIFEST file.
Get Service Object in “Bundle B” Activator class

Service Trackers:


Sometime one interface have multiple implementations and bundles export the same interface package, and each bundle register different Implementation Object in the Bundle Context with same interface class name.  Service Tracker is the way to filter the implantation by specific properties such a way consumer bundle can get right implementation service. 

Author

Sunday, August 27, 2017

OSGi Architecture

OSGi is a standard that defining Dynamic Component Development for Java.
Its specification that define the API to develop dynamic components in java application development. As per OSGi application composed of several components and components are packaged as bundle.

Java to build complex application is big challenge where OSGi defining way to divide application into several bundles and each bundle composed with several components.
OSGi is providing environment where all these bundles and components can communicate each other such way we can run complex application.

Component:

Component is small unit of application and it called as some feature in the application. Component cam work independently or it can collaborate with other component to full fill the requirement in the application.

Bundle:

Bundle is composed with several components and OSGi we package components as bundles and we will deploy bundles into OSGi container.

Services:

Services are part of component and it will full fill one more tasks. OSGi we can export and import services such as way we can make available services to other components or bundles.

Modules:

Module is basic terminology in OSGi modular development and these modularity concept achieved through bundles. Modules and bundles are same.

 OSGi Layers.

OSGi architecture divided into several layers. I have taken the following picture from enRoute.

Source of image: enroute

Bundles:

Bundles are packaged components developed by OSGi developers. Bundle is packaged as JAR file and we can deploy into OSGi containers.

Services:

Services layer provide mechanism to share services between bundles. It will provide environment to register services and make available to other bundles. We have concept called publish-find-bind. We have different framework to achieve this concept. Declarative Services and Apache Service Component Runtime are the implementation for this concept.

Life Cycle:

Life Cycle is responsible to manage lifecycle of bundles. OSGi bundle have several lifecycle stages install, start, update, stop and uninstall. All these stages handles in this layer.

Module:

Module layer is define the import / export the code of the bundles. Usually we will use export/import headers in the OSGi manifest file that will handle in module layer.

Execution Environment.

Execution Environment layer define the classes and methods are available to the platform.

Security:

Security layer define standards security to the OSGi applications. How your modules available to the other platforms and it will define some permission system.

Java VM

Java VM layer is provide the JAVA run time environment. Its basic layer in the OSGi.

Operating System

It will provide standard Operating System to the OSGi environments.

Deployment

OSGi provide run time container there we can deploy bundles. Bundles are standard package system where we can package all java classes and interfaces. Bundle is JAR file. We have different commands provided by OSGi command line interface to deploy bundles.

Implementation

OSGi specification implemented by several vendors’ popular vendors Equinox and Apache Felix. We can develop OSGi application which target to anyone of these implementations. Both implementations are followed the OSGi standard specification. There may be few features vendor specific but most of the implementation as per OSGi specification.

Reference:


Author

Monday, August 21, 2017

OSGi Sample Bundle Development with Eclipse

OSGi is java modularity development framework. We can divide complex application into multiple modules and OSGi will responsible to communicate all modules and make it as single application.

OSGi is framework provides the run time environment so that all these module can communicate each other. In OSGi terminology we can call each unit as bundle. Bundle is independent component in OSGi and it can run in OSGi container. OSGi container is responsible to handle lifecycle of bundle.

Follow below articles for Basics of OSGi and Bundles





In this article we are going to see develop basic bundle development using eclipse and will run in OSGi run time environment.

Basic OSGi bundle development without eclipse and run in Apache Felix OSGi run time environment was explained in below article.


Prerequisite.

Install Java 8 and set JAVA_HOME environment variable.

Download latest version of Eclipse from below link


We are using eclipse-jee-oxygen for this example.

Any bundle in OSGi need activator java class and it is responsible for managing bundle lifecycle in the OSGi container. So each activator class should extends “BundleActivator”.
When we create bundle with eclipse it will create basic template with Activator class and if we observed the activator class, that extends “BundleActivator” class.

Once you download the eclipse extract it local machine then you can find “eclipse” directory. Navigate to “eclipse” then click on eclipse icon then eclipse will be started and initially it will ask workspace for your projects then select your workspace directory.



Create OSGi sample bundle in Eclipse.

Go to File à New à Project

It will open project selection Dialog then select “Plugin-in Project” click on next.



Once click on next then you can see another dialog there we need to provide your project name then click on next.

Project Name: com.liferaysavvy.example.LiferaySavvyWorld
Plugin-in Targeted Run with Select OSGi framework à Standard



Once click on next we can see other dialog there it will ask information which will be used in the bundle MANIFEST file. Information like name, version, vendor and execution environment.

Click on Generate Activator class check box then give your Activator class name.


Once click on Next it will ask you select OSGi template and click on Crete Plugin using template then select “Hello OSGi” so that it will generate bundle with activator class with lifecycle methods



 Finally click on finish button then bundle will create with basic activator class.
The following is basic OSGi bundle project view in eclipse



Activator

Activator is java class which handle the bundle lifecycle management in the OSGi container. It will extends the “BundleActivator” class. We have different lifecycle methods as follows

start(--) :  This method will take the argument BundleContext and container will invoke this method to start bundle.

stop(--): This method also take BundleContext as argument and OSGi container will invoke this method to stop bundle.


package com.liferaysavvy.example.liferaysavvyworld;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

     /*
      * (non-Javadoc)
      * @see org.osgi.framework.BundleActivator#start(org.osgi.framework.BundleContext)
      */
     public void start(BundleContext context) throws Exception {
           System.out.println("Say Liferay Savvy World!!");
     }
    
     /*
      * (non-Javadoc)
      * @see org.osgi.framework.BundleActivator#stop(org.osgi.framework.BundleContext)
      */
     public void stop(BundleContext context) throws Exception {
           System.out.println("Goodbye Liferay Savvy World!!");
     }

}


MANIFEST.MF:

MANIFEST.MF is deployment descriptor for the bundle and have more information and it will be used by OSGi container. This is core resource of the bundle.


Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: LiferaySavvyWorld
Bundle-SymbolicName: com.liferaysavvy.example.LiferaySavvyWorld
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.liferaysavvy.example.liferaysavvyworld.Activator
Bundle-Vendor: LIFERAYSAVVY
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Import-Package: org.osgi.framework;version="1.3.0"


Bundle-ManifestVersion:

 This header tells that bundle follows the OSGi specification and value 2 specified, it is following SGi specification Release 4; if it is value 1 its means it is following the compliant with Release 3 or earlier.

Bundle-Name

Its human readable bundle name

Bundle-SymbolicName:

Its important header for bundle and it is unique name used to refereeing it in other bundles when it communicate to other bundles.

Bundle-Version:

Its simple version number for the bundle. We can start and run version specific bundles in the OSGi container.

Bundle-Activator

Bundle-Activator headers tells the Activator class name and it will used to manage life cycle of bundle by OSGi container.

Bundle-Vendor

The Bundle-Vendor header is just human readable name which tell the vendor who implemented the bundle.

Bundle-RequiredExecutionEnvironment:

Which tell the Jave environment is required to execute the bundle.

Import-Package

This header is very important and it tells which packages are required to execute the bundle. When the bundle depends on the other bundle then we have specify the bundle symbolic name so that it will be handled by the OSGi container. Basically each bundle must import OSGi implantation bundle it’s like “org.osgi.framework;”

Executing a bundle

Select bundle and right click on bundle

Run As à Run Configuration





Select your bundle and Select “org.eclipse.osgi” for Target platform then Apply à Run



You can see Output in the console as follows. Bundle will be started by OSGi container then it will invoke activator start method start() then we can see message in the console.





If you want execute bundle in Apache Felix environment then select Apache Felix OSGi implementation for Targeted platform.
Just type Felix in the filter text input then you can see Felix implementation jars.



If you want execute bundle in OSGi equinox then select targeted platform equinox

We can also export bundle and execute in standalone OSGi containers. Just export bundle as JAR file from eclipse and run jar file in other OSGi containers
Here is example how to run bundle in Apache Felix Environment. Look at “Install and Start bundle in OSGi” Section.


Author

Recent Posts

Recent Posts Widget

Popular Posts