The problem is mostly due to the class loading algorithm in OSGi. As each module need to specified what package it needs setting these packages in "Import-Package" inside META-INF/MANIFEST.MF of the bundle. But sometime your application load the driver dynamically in runtime, or the 3rd party library did not specified the import in their settings.

What I normally do when I am in the middle of development is to temporary resolve this problem in the JBoss Fuse Karaf container, for instance this example, I am using the c3p0 pool in servicemix, but it needs to dynamically lookup the postgresql database. What I will do is to install both servicemix c3p0 bundle and postgresql bundle

But this is not a good idea when you want to package the application, I used the dynamical import when developing because I am the only person running the container, and the dependency may change rapidly when I am developing, but this is not the best way to do in OSGi, instead of a strict modularized system, it will search the public exported packages to find a match instead of the careful normal calculation. Not a good practice. That's when I want to deploy my application into production, is I will create a fragment bundle. There is no big secret about this "fragment bundle", all you have to do is to specify a Fragment Host. And all the content in your fragment bundle will be made available to that host. From my example, all I have to do it to create an empty bundle, and have my servicemix c3p0 bundle as the fragment host and import postgresql host.

To be more specific, create a JBoss Fuse blueprint project, remove all the unnecessary blueprint.xml or java classes (Basically an empty project), Then in your pom.xml, find the maven plugin, add your fragmented Host and package you need in Import-package tag.

<!-- to generate the MANIFEST-FILE of the bundle -->

<plugin>

<groupId>org.apache.felix</groupId>

<artifactId>maven-bundle-plugin</artifactId>

<version>2.3.7</version>

<extensions>true</extensions>

<executions>

<execution>

<id>bundle-manifest</id>

<phase>process-classes</phase>

<goals>

<goal>manifest</goal>

</goals>

</execution>

</executions>

<configuration>

<instructions>

<Bundle-SymbolicName>demojobfrag</Bundle-SymbolicName>

<Private-Package>org.blogdemo.demojobfrag.*</Private-Package>

<Fragment-Host>org.apache.servicemix.bundles.c3p0</Fragment-Host>

<Import-Package>org.postgresql,*</Import-Package>

</instructions>

</configuration>

</plugin>

And then deploy this bundle first along with your application. This is my MANIFEST.MF look like after packaging it.

This is really nice to read as we just added a PgSQL server to our integration space and deploying the driver is turning out a lot more tricky than even SQL server jTDS. I used DBCP though so will have to apply it to my case however the analysis is clear concise and very informative.

I love Karaf, Fuse, Camel but this class loading hell you can experience needs to be addressed on a fundamental level.

Fuse and A-MQ 6.3 GA has just went out. Maybe, you would think this is just only a minor version release why should I care? Hold your thoughts on that! Because they have done a lot of improvements and also added many new features into this release.

Besides various bug fixes and making sure Fuse Fabric is much more stable. There are two major change in this version update:

New Tooling in JBoss Developer Studio (JBDS) 9.1 GA. Newer Apache Camel version – Camel v2.17.
I was really impressed by the work put in to make developing Camel application much simpler. First is the installation of tooling itself. Now it has a all-in-one installer so you don't need to worry about which plugins you need to check. See the videos below to see the new "Getting Started" of Fuse 6.3.

And If you notice from the above video, the presentation of camel route in JBDS has also updated. It fixed some of the miss representation of logic and making it easier to read.

I just realized that I did not do a getting started for Fuse Integration Service 2.0 Tech preview before I did the pipeline demo, thanks for those of you who reminded me! :)

To get started with FIS 2.0, for people who has just getting to know the technology, here is how I interpret it. Basically, it's divide into two aspect,

1. Integration development, FIS uses Apache Camel as the core technology that creates, orchestrate, compose microservices into a super lightweight thin integration layer, and become the API provider and service orchestrator through exposing RESTful or messaging service endpoints. And you can choose to either package and run it with Spring-Boot or Karaf.

2. Application Deployment and Management, FIS takes advantages of OpenShift platform, and allows you to separately deploy the micro-integration service among distributed environment, at the same time takes care of the failover, high availability, load balancing and service lookup problem for you.