You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Balázs Zsoldos <ba...@everit.biz> on 2012/07/31 23:29:38 UTC
Possible non-specification extensions in aries blueprint
Hi,
I am planning since a year to make some extensions concerning to the basic
blueprint functionality to be able to create more complex business logic
for bundles. Till now I have been busy therefore I planned to have the
features I want in July. One month late I can start the development.
A couple of months ago I wrote down what I would like to have at
https://www.osgi.org/bugzilla/show_bug.cgi?id=143 to let others writing
notes.
In summary:
I would like to have a function called createChildContainer() in the
BlueprintContainer interface. A container may have many children, they
build up a tree. A child sees the components of the parent.
Why would it be good?
More complex namespace handlers could be written that handle the
ManagedServiceFactory like this:
<cm:managed factoryPid="com.acme.designate.factory"
componentIdPrefix="someUniqueAttributePid">
<bean .... >
<property key="a" value="${attributeName}"
<bean>
<reference ... />
<service ... />
<c:choose>
<c:when test="${someAttributeId eq 'value'}">
<reference ... />
<bean ... />
<service ... />
</c:when>
<c:when test="${parent.parent.otherAttributeId eq 'value'}">
...
</c:when>
<c:otherwise>
...
</c:otherwise>
</choose>
</cm:managed>
In my opinion a possibility like this with a namespace similar to the
Metatype XML structure would really give a boost to the blueprint
technology. In this case when someone designs a module the API and the
metatype interface should be designed together.
After checking the source a lot of Gemini and Aries I made the decision to
go in the aries way. Now I have two options:
- Wrap the aries.blueprint.core in a custom bundle and extend with the
possibility of having child blueprint containers
- Creating a branch on GitHub and write the changes inside the source of
aries blueprint classes
My questions would be:
- Which way would you recommend?
- In case of a Github branch do you see any chance that it will be
merged into the trunk?
- In case of wrapping option (where some copy paste and modification is
done) do you see any chance to merge it into the trunk?
- Is there anyone who things that this feature would be useful or
useless?
In case there is less chance I would choose option two so first I wrap the
aries blueprint code. After a while if you like the solution you still have
the chance to take any code back by using simply a diff tool on the classes.
Regards,
Balazs Zsoldos