Tuesday, July 22, 2008

Everything can be a bundle

One of the demanding aspect of server side OSGi is to reuse the existing classic jar files as bundles. The other aspect of the spectrum is to diagnose these bundles. Out of the lot BND (Bundle Tool) tool from Peter Kriens helps you to create and diagnose OSGi R4 bundles.

The key features are,

1. Show the manifest and JAR content of a bundle
2. Wraps a JAR as a bundle
3. Create a bundle from a specification and a classpath
4. Verifying the validity of the manifest entries

This tool can be used as a,

1. Command line tool
2. Eclipse plugin
3. Maven plugin
4. Ant plugin

You will find more information about this tool here.

Apache Felix folks has written a Maven2 plugin based on BND called maven-bundle-plugin to create bundles.

You'll find a really cool article on usage of BND is available here.

Monday, July 14, 2008

Maven 2 GPG Plugin

Maven 2 GPG Plugin, allows to sign attached artifacts with GunPG. One of the tedious processes involved in releasing a project is to sign its artifacts. Some of the releases might contain 10-15 artifacts. Ex: WSO2 WSAS etc. So in order to get the release process smoother, one could just need to add the following plugin into the parent pom.xml,

<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactid>maven-gpg-plugin</artifactid>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>


The latest version of this plugin is 1.0-alpha-4 as at 2007-09-28.

Then using "mvn clean deploy" will sign the artifacts in addition to md5 & sha1. It's advisable if the prior plugin be added in a "profile" section. Then only at the release time, "asc" files are generated. Trust me, when you have A LOT OF artifacts to be signed, above plugin is a life saver.

Wednesday, July 9, 2008

Partial solution to TCCL problem in OSGi

One of perennial problem that OSGi uses asked from mailing lists is to resolved the problem of TCCL. As I have mentioned in the blog post "OSGi and TCCL dilemma", there is no proper definition is available in OSGi R4.1 specification for TCCL.

On the other hand Eclipse Equinox OSGi implementation has taken steps to prevent this problem with the invent of ContextFinder (CF). When the framework starts, Equinox sets the framework TCCL to CF. Hence, all the bundles spawn from this framework will set its TCCL to CF. CF finds classes and resources from the classloader associate with the current method of the execution stack. (java.lang.SecurityManager#getClassContext). This is not the complete answer to the problem, but it will solve most of the common scenarios. Thus, it's very easy to use this concept and apply to other OSGi implementations as well, such as Apache Felix.

WSO2 is align with producing products that are OSGi enabled. The underline infrastructure of these products uses a product called "Carbon", which is an OSGi wrapper powered with either Eclipse Equinox or Apache Felix and provide a
Web Services infrastructure powered by Apache Axis2. Carbon uses the "servletbridge" design principle to bridge OSGi and Servlet container. Hence, Carbon is one such infrastructure that harness the benefits of server-side OSGi. Though Carbon defaults to Equinox and Felix OSGi implementations, it has give a very powerful API to integrate other OSGi implementations as well.

You will be able to find the source code from "svn co https://svn.wso2.org/repos/wso2/trunk/carbon".

Nice thing about Carbon is that it can switch between Equinox or Felix based on users preference. It can switched to any other OSGi implementations that is registered with too. Carbon uses the prior mentioned ContextFinder principle to solve the TCCL problem and I think it's a very fair assumption until OSGi specification mandate on the TCCL.

One of the very first product that is scheduled to be released on this month on top of the prior mentioned infrastructure is "Data Services Solution", which is a complete solution for data services via web services.

Saturday, July 5, 2008

Light weight, OSGi based, Axis2 powered, web services application server in 5 minuets

Few days back I blogged about "Embed Eclipse Equinox in a Servlet Container". Let's extend this idea a little bit more to write your own light weight, OSGi based, Axis2 powered, web services application server.

There is an ongoing effort to extend Axis2 Web Services engine to deploy as a bundle in an OSGi environment. The purpose of this extension is to allow deployed bundles to provide services and modules which will be recognized by OSGi based Axis2 engine and deploy them.

Let's create the light weight, OSGi based, Axis2 powered, web services application server using Eclipse Equinox OSGi implementation and Apache Tomcat.

1. Download Apache Tomcat
2. Download bridge.war from Eclipse Equinox.
3. Download commons logging (org.eclipse.equinox.common_3.3.0.v20070426.jar) bundle from Eclipse Equinox.
4. Copy the downloaded bridge.war to Apache Tomcat webapps directory
5. svn co https://svn.apache.org/repos/asf/webservices/axis2/scratch/java/saminda/osgi_test osgi_test
6. Go to osgi_test directory and type "mvn clean install -U". You need Maven2 build system.
7. Go to osgi_test/distribution/target directory and unzipped distribution-1.0.0.zip.
8. Copy all the bundles from distribution-1.0.0/plugin folder to /webapps/bridge/WEB-INF/eclipse/plugins and copy commons logging bundle too.
9. Restart Tomcat
10. On the osgi> command prompt start all bundles except fragment host bundles.

11. http://localhost:8080/bridge/services/Version?wsdl
http://localhost:8080/bridge/services/Version?wsdl2
http://localhost:8080/bridge/services/Version/getVersion

You have your personal light weight, OSGi based, Axis2 powered web services application server.