Open bjhargrave opened 12 years ago
Comment author: Balazs Zsoldos <balazs.zsoldos@everit.biz>
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)
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
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:
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:
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>
Original bug ID: BZ#143 From: Balazs Zsoldos <balazs.zsoldos@everit.biz> Reported version: R4 V4.3