Posts tagged "Apache Felix"

How to have changes to bundles recognized and applied during development?

CQ and Sling have watches folders with the name of “install.” Among other things, these folder are watched for *.jar files for bundles being added or changed. These bundles will automatically will be loaded or reloaded in the Felix OSGi framework as needed. Note the emphasis on the phrase, as needed. Just changing a bundle within the CQ repository does not guarantee that your bundle will be reloaded. While developing bundles, it is important to know how CQ/Sling determines that a bundle needs to be loaded or reloaded in Felix after it is changed in the repository. Bundles will be loaded/reloaded after a bundle jar has been added or update when:

  1. The bundle does not already exist in the OSGi framework
  2. The bundle version is different and more recent
  3. The bundle version has “-SNAPSHOT” at the end

It is worth noting that it is good practice to use the “-SNAPSHOT” version for bundles that are in development and are not in their final version. One way the naming convention help is that it keeps from having problems telling which bundle build to use to deploy versus builds used in development. No “-SNAPSHOT” at the end, this is the final version. “-SNAPSHOT” at the end, the developer hasn’t finished it yet and it will change.

Here are some example of how this will work for a bundle called, my-bundle::

Existing: my-bundle-1.0.0
Added to repository: my-bundle-1.0.0
Result: Felix will NOT reinstall the bundle. It is assumed that this is the exact same version of the bundle of a released bundle

Existing: my-bundle-1.0.0
Added to repository: my-bundle-1.0.1
Result: Felix WILL install the bundle with the later version of the bundle added to the repository

Existing: my-bundle-1.0.0-SNAPSHOT
Added to repository: my-bundle-1.0.0-SNAPSHOP
Result: Felix WILL reinstall the bundle. Sling treats the bundle as being in development and considers each installation to be a new build.


Decontructing Experience Services: Apache Felix

It is amazingly hard to get application components to cooperate with one another, especially if the need to be dynamically added and removed. The OSGi specification attempts to standardize the integration of very different components to work together. And it tries to do this in such a way that the components can be brought in remotely and added to the larger application with minimal disruption.

Apache Felix is a Java implementation of this specification that is used by ADEP Experience Services. The Java content respository (JCR) that is the foundation for Experience Services can contain executable code, but how that code interacts with other executable code is not defined by the JCR itself. Felix provides the framework for how code executes and interacts other components. It provides a way for components to be started up and shut down properly.

Installing and removing functionality within Experience Services is done with packages. Packages are the basic units of functionality for Experience Services and these packages are OSGi bundles. Felix provides the way for Experience Services to bring packages in, deploy them, undeploy them, start them and stop them without having to restart the whole server.