From the Jackrabbit web site:

January 27, 2010: Apache Jackrabbit 2.0.0 released

Apache Jackrabbit 2.0.0 is a fully compliant and production-ready implementation of JCR 2.0.

Get it while it's hot.

It is a pleasure to announce that the dev.day.com blog has been migrated onto CQ5.3. Along the way, we have brought the visual design up to date and added the portal page.

Thanks a lot to the (small) team that made it happen!

Following up on Jon Marks' post on standards relevant for content management Justin Cormack has put together a "Standards Diagram for Content Management" Prezi landscape. Nice work!

The part "structuring" in Justin's presentation contains Docbook and DITA. Theresa compared these two standards a while ago:

| View | Upload your own

OSGi Declarative Services components are configured by properties defined by the component developer in the component descriptor and by configuration managed by system administrators using the OSGi Configuration Admin Service. The combined set of properties is traditionally made available to the component as a Dictionary calling the ComponentContext.getProperties() method. The component context is provided to the activate method called when the component is activated.

This makes configuration of components very simple, since the component itself does not have to care where configuration comes from and how it is maintained. In addition, a component always knows it is starting from scratch when the activate method is called. This is because a component instance is never reused and a component reconfiguration means the component is deactivated and activated with the new configuration.

There are some drawbacks to this solution, though:

• Reactivation of a component may be an expensive operation. Particularly if the component provides a service which is heavily used and relied upon, such as for example the SlingRepository service in Communique 5.
• If a component is keeping internal state, e.g. gathering statistics, reactivation of the component will cause loss of this state.

This is where the new Declarative Services specification version 1.1 kicks in and improves much. First of all, configuration may be updated dynamically without reactivating the component. Second a component may declare itself as not needing configuration or even as requiring configuration thus only activating the component if configuration is actually available from the Configuration Admin service.

To use dynamic reconfiguration you have to declare a method to take this updated configuration in the modified attribute of the component element. When using the Apache Felix Maven SCR Plugin, use the modified attribute of the @scr.component tag:

 @scr.component modified="modified" 

and define a method taking the configuration, for example:

 private void modified(Map config) {
     // apply the configuration dynamically
 }

Unless the configuration may cause the component's references to be modified the component configuration is now dynamically provided without reactivating the component.

The method defined in the modified attribute has the same requirements as the activate method: It may be have any access modifier (but should not be public) and it may take any combination of ComponentContext, BundleContext, and Map arguments. Of course for a modified the primary useful type Map as in the example above<.

If you know your component cannot be configured or if you absolutely need configuration of your component, you can declare this desire using the configuration-policy attribute of the component element (or the policy attribute of the @scr.component JavaDoc tag):

optional

Configuration from the Configuration Admin Service is provided to the component if available. This is the default setting and is the same as in the previous Declarative Services specification.

require

Configuration from the Configuration Admin Service is required for the component to be activated. If the configuration is deleted, the component will be deactivated. This setting allows for a component to be controlled by the existence of configuration.

ignore

Configuration from the Configuration Admin Service is never retrieved on behalf of and provided to the component. If your component has no configurable properties, this setting makes sense.

Note: To use the functionality described in this article, you have to use a Declarative Services 1.1 implementation such as Apache Felix SCR 1.2.0 or newer.

The OSGi Declarative services specification defines three types of components:

1. Immediate Components are immediately created when the providing bundle is started and may or may not provide services
2. Delayed Components provide services but are only created when used by a service consumer.
3. Factory Components are created on demand by calling the ComponentFactory.newInstance(Dictionary) method of the Component Factory service registered for the component.

This blog is about a special behaviour of delayed components which may seem unexpected in the first place: Delayed components are created (activated) on-demand (when they are first requested) and have to be deleted (deactivated) as soon as there is no user any longer (Chapter 112.5.4, Delayed Component, in the Compendium Spec; see also FELIX-1825)

The intent of this behaviour is to reduce the system (or bundle) startup time in that delayed components are only instantiated when really used. In addition memory consumption may be reduced at times when the service is not used. The drawback is, that the service is activated and deactivated if there is a single consumer which uses the service for short periods of times only. An example of such an oft used service is an OSGi EventHandler service, which is got by the Event Admin service when ever an event must be delivered and released after the delivery.

How does a Component become a delayed component ?

By default a component providing a service is a delayed component unless the component is explicitly declared as an immediate component. If you are using the Apache Felix Maven SCR plugin, a component is (by default) delayed if the @scr.service tag is used. Thus the above activation and deactivation rules apply. To turn a service component into an immediate component, you have to set the immediate attribute to, as in :

 @scr.component immediate="true" 

Shall I change all my components to be immediate components ?

The short answer is: It depends.

Here are some general rules of thumb:

• If your service can be expected to be immediately used and not released until system shutdown, defining the component as delayed does not make much sense. In this case, it is probably better to explicitly define the component as immediate. An example of such a component is a Servlet service in Sling, which is immediately used by the Sling Servlet Registry.
• If your service is in fact a service factory (using the servicefactory attribute, you cannot declare the component immediate, because service factory components are always delayed
• If your component is used a lot for short periods of time, you should probably define your service as an immediate component. An example of such a service is an OSGi EventHandler service.
• If you want to maintain state in your component and make that state available to clients by registering a service, the component should be defined as immediate. An example of such a service might be statistics provider, which gathers statistics and provides them through its service API.
• If your component is only seldom used it would be best to define it as a delayed component. An example of such a component in Communiqué 5 might be a workflow step service, which implements very specific behaviour.

Looking at the Bundle details in the Web Console you will notice a number of entries providing information about the bundles. In this article I will explain a bit more about the information regarding the identification of bundles.

Looking at the following screen dump you will notice a number of identifaction details of a bundle:

1. The bundle identification number. This is a number uniquely identifying the bundle. This number assigned to the bundle at the installation time of the bundle and never changes. These numbers are also unique within the framework. Never will a bundle ever be assigned the same number, even if the currently installed bundle is uninstalled.
2. The bundle name. This is a descriptive name of the bundle which is ignored by the OSGi framework. This name is provided by the bundle developer as the contents of the Bundle-Name manifest header.
3. The bundle symbolic name. This is a symbolic name of the bundle, which is used by the OSGi framework together with the bundle version number to identify the bundle. That is, no two bundles with the same symbolic name and version may be installed in a single OSGi framework. But multiple bundles may be installed which have the same symbolic name but differ in their version number. This symbolic name is provided by the bundle developer as the contents of the Bundle-SymbolicName manifest header.
4. The bundle version. The version of the bundle is used to convey the development state of the bundle as a whole. Together with the bundle symbolic name the version number must be unique within an OSGi framework (see the description of the bundle symbolic name). Note that the OSGi framework places only synthatic restrictions on version numbers. This version is provided by the bundle developer as the contents of the Bundle-Version manifest header.
5. The bundle location. The bundle location is basically just a string. It is recommended that this string follows the syntax of an URL and it may even be used as an URL to update the bundle from: The Bundle.update() method uses the bundle location to try to access an updated bundle version. This is not used as such though in Communiqué 5 where the bundle location merely indicates where the bundle has initially been installed from. This value is provided by the administrator as the location parameter when installing the bundle through the BundleContext.installBundle(String location) or BundleContext.installBundle(String location, InputStream input) method. This value will not changed when the bundle is updated.
6. The last modification time. The last modification time is set by the framework when the bundle is modified. A bundle is modified when it is installed, updated or uninstalled. Starting and stopping the bundle does not change the last modification time. This information can be used to verify that a bundle update has really been executed by the OSGi framework.

As can be seen a number of identification details are set on installation time and never change afterwards and some details may change over time when a bundle is updated.

So here are the rules regarding these details:

• The bundle identification number is assigned by the framework and is never reused.
• The bundle location is assigned from the location parameter when the bundle is installed and never changes during the existence of the bundle. No two bundles will ever be installed at the same time with the same bundle location. As such this location is also a unique identifier for bundles. But in contrast to the bundle identification number, the location may be "reused". That is, once a bundle with a given location has been uninstalled another bundle may be installed with the same location.
• The bundle symbolic name and version together also uniquely identify an installed bundle. These values are taken from the bundle manifest and therefore may change when a bundle is updated. But it is not allowed for multiple bundles to be installed with the same symbolic name and version at the same time.

So, whenever you update a bundle, either placing it into an install folder in the repository or through the Web Console, expect the bundle version and/or symbolic name to change. But both the bundle identification number and the bundle location will not be modified. The bundle last modification time will reflect the time at which the bundle has actually been updated by the framework.