Hi, If you haven't already done so, please open a bug in bugzilla for tracking this.
Tim. From: Balázs Zsoldos <[email protected]<mailto:[email protected]>> Reply-To: OSGi Developer Mail List <[email protected]<mailto:[email protected]>> Date: Tuesday, May 22, 2012 7:50 AM To: OSGi Developer Mail List <[email protected]<mailto:[email protected]>> Subject: [osgi-dev] Blueprint extensions with metatype configurations Hi, as you might remember I would like to have some enhancments concerning to the current blueprint solutions. I had the feeling that first I should check the Configuration Admin and Metatype part of the specification. Well I do not say that I tried all of it but I spent some time reading it. After reading these I am getting the impression that I could really use these parts of OSGI if I had minor enhancements in them. Concerning to the blueprint xsd I could imagine the following enhancement: <!-- A configuration that is registered via the configadmin. --> <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="${someAttributeId eq 'value2'}"> ... </when> <otherwise> ... </otherwise> </choose> </managed> I hope the xml fragment is pretty self explaining. There could be metatype-designate (or some similar name) tags in blueprint.xml where parts could be defined that come active only when a new configuration is available. In these tags we could use the attributes of the configurations with el-expressions. You can notice the choose-when-otherwise tags as well that could be used to build up different object hierarchy based on the different configuration. This structure is simply stolen from JSLT :). Also the reference wiring would be useful that I mentioned in one of my previous mails. I think I will have time somewhen around June to spend nights developing a solution based on one of the OSS already working Blueprint solution as a namespace extension. However I would be amazingly happy if the blueprint spec writers would think of a similar solution. If anyone has any suggestion how to change this concept please let me know. Let me know please if there is already a working solution similar to this. I started checking the Aries blueprint till now but I had not much time. Thanks and regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz<https://www.everit.biz/>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
