Blueprint Container enhancements

[bjhargrave]

Original bug ID: BZ#143
From: Balazs Zsoldos <[email protected]>
Reported version: R4 V4.3

[bjhargrave]

Comment author: Balazs Zsoldos <[email protected]>

In the end of June I would like to start enhancing one of the existing Blueprint solutions with the following features:

• Having the possibility of Blueprint Container trees. A bundle has one blueprint container that may have child blueprint containers and the children can have children as well. Users may create child Blueprint Containers programmatically via the BlueprintContainer interface (like installing a bundle at runtime)

  • A child Blueprint Container can see and reference all of the Component Instances created by the parent but a parent cannot see the component instances of a child. Also children cannot see component instances of siblings.

• Adding new tag that can create child Blueprint Containers based on the ManagedServiceFactory interface (Configuration Admin). In the created child blueprint containers the attributes coming from configadmin can be used as El Expressions in the Child Blueprint Container. The relationship between Blueprint Containers can be one-to-many as a ManagedServiceFactory may creates more child Blueprint Container (with it's reference, bean and service tags).

• Based on the El Expressions the , , solutions may be used (like in JSTL) inside a child Blueprint Container blueprint.xml.

• When a Blueprint Container is unregistered all of it's children are unregistered as well.

• When a reference is not available anymore one of the followings happen:

  • A ServiceNotAvailableException will be thrown if any of the functions of the service is called
  • The BlueprintContainer is unregistered (and all of it's children of course)

• Standard API for NamespaceHandlers. Gemini and Aries Blueprint currently contains a similar implementation of NameSpaceHandler method. The best could be if the general API would be designed in the way that the components written for both existing implementations could work (with maybe minor modification or via proxy API)

• Blueprint.xml files may be imported into another blueprint.xml file. This is necessary as soon as we can define children like the ManagedServiceFactory fragment not too have too long and hard to read blueprint files.

• With a custom namespace a similar structure like the metatype.xml could be defined with the differences:

  • The options for enumerated attributes could be defined as Service Filters expressions. When a new service is available that meets the necessary filter it will be part of the enumeration. When a service is removed it will be removed from the Metatype Attribute enumeration.
  • The service filters of Metatype Attribute enumerations may contain el-expressions.
  • The metatype designate elements can have a groupId with a default value. Group ids are alphabetical words separated by dots (e.g. group1.childgroup). A Felix Web Console could for example take settings into a tree based on this. Groups are only default values, they can be changed at runtime and persisted (drag and drop the nodes of the tree on the interface). An administrator can build up a pretty easy to use configuration application for a whole OSGI server with these methods (like Glassfish admin console).

These are my ideas for now. Some of them may already be available somewhere. If anybody knows about that please let me know as I would not like to work unnecessarily. Also if you have any ideas please do not keep it to yourself. I would like to have a long living (almost perfect :)) solution that may is a good base for the enhancement of the specification.

If we have the metatype extension as well that can open to a pretty new word. Jdbc DataSources could be defined via admin console and also connection pools (selecting from the existing datasource services from combo boxes). And for this only some minor blueprint configuration would be necessary.

Here is an example of a managed service or managed service factory fragment (that opens a new child Bluepring Container always as a new config is available and unregisters it when the config is not available anymore):

<managed factoryPid="com.acme.designate.factory" componentIdPrefix="someUniqueAttributePid">
    <bean .... >
       <property key="a" value="${attributeName}"
    <bean>
    <reference ... />
    <service ... />      

    <choose>
        <when test="${someAttributeId eq 'value'}">

            <reference ... />
            <bean  ... />
            <service ... />

        </when>
        <when test="${parent.parent.otherAttributeId eq 'value'}">
        
             ...

        </when>
        <otherwise>

             ...
        
        </otherwise>
    </choose>
  
</managed>