Posts tagged "Apache Sling"

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.

 

Deconstructing Experience Services: Apache Sling

Apache Sling implements a content management system that uses a Java content repository (JCR), an object database, to store its content and OSGi to add functionality and deploy content. It has server-side scripting and can use multiple languages such as Ruby, JSP and javascript.

Sling forms the basis of the Web Experience Management (WEM/CQ) within Adobe’s ADEP Experience Services. It is robust and makes Web sites easy to develop and then deploy into production. In addition, it has a system for managing digital assets stored within the JCR. ADEP Experience Services implements Sling using its CRX JCR.

In an earlier post I talked about my experience years ago with a content management built on top of a object database called Userland Frontier. Frontier allowed content to be totally separated from the code and HTML used to implement it. That experience has given me a deep appreciation for Web Experience Management.

Within WEM content is not HTML, but the text, photos and other media used as raw material for Web pages. Content is rendered to HTML when needed based on metadata of the content and the context the content is being viewed. If a person views the content from their desktop computer, the content will be rendered for the desktop computer. If another person views that same content from their smart phone, the content will be rendered for the smart phone. The context drives the way content is rendered, but context is not limited to device type. Content can be rendered for women differently than for men. Or it can be rendered differently for a person in one city than for someone in another. Sling makes this smart rendering of content possible and WEM gives the owner of the Web site the tools to use it.