Hi, Am 03.02.2012 um 15:02 schrieb Martin Ždila:
> Hi Felix > > On Fri, Feb 3, 2012 at 2:11 PM, Felix Meschberger <fmesc...@adobe.com> wrote: >>> Are there any plans for extending MetaType service in the future >>> specifications? Current implementation is not extensible and we can't >>> use additional proprietary properties. >> >> Yes the implementations follows the spec and as such only supports the >> elements defined by the spec. As an extension to the spec, the API to read >> and parse the metatype files is exposed, though. > > I was actually asking about extending the specification itself :-). I > know that Felix implementation follows exactly the specification and > this is just perfect as is. I don't know of anything concretely at this point in time. > >>> We would like to have for example custom properties. In XML it is >>> possible to use other namespaces, but it is not possible to access it >>> via MetaTypeService. Custom properties could be for example additional >>> validation properties (inspired from JSR-303). >> >> Validation is also predefined by the spec and as such is implemented >> accordingly. > > There is some validation in the Metatype, like data type, min, max, > required, but there is no way to tell that value of some AD must obey > provided regular expression. > > Also for example options are static currently but in our system we > have "interface Enumerable" where the implementations are registered > under a name and provides list of option lavel/value pairs. Sure, this > is proprietary, but metatype.xml with MetaTypeService has no mean to > get any proprietary data (eg. custom properties). Yep, it is not pluggable (e.g. providing supporting a validation service)... > >>> Another thing, there is no way to describe various complex structures, >>> for example arrays with complex structures: >>> >>> user.1.name=John >>> user.1.surname=Parker >>> user.1.age=30 >>> user.2.name=Fred >>> user.2.surname=Flinstone >>> user.2.age=5923 >>> ... >> >> This can easily be done with two factory configurations. > > I known about this alternative but I wish also my way was possible to > describe in metatype. > >>> ~~~~ >>> >>> Another missing feature is to explicitly provide PID for >>> Configurations created from configuration factory. Currently the PID >>> is generated by the implementation, for Felix it is >>> <factoryPid>.<UUID> but this makes it hard for human to distinguish >>> multiple instances. >> >> Yes, this is how the Configuration Admin specs states it: The >> ConfigurationAdmin.createFactoryConfiguration methods generate a unique PID >> automatically. There is no way to predefine it. It just so happens as an >> implementation detail, that the Felix implementation does it like this. > > I was again talking about extending the specification first :-) > >>> Also, is there some discussion groups where future specifications are >>> discussed? >> >> AFAICT There are discussions in the OSGi Alliance to update Configuration >> Admin. One idea is the notion of a Configurable (see Peter's blog on this >> subject) where a configuration object is created ORM-style from the >> configuration data. > > I am already using Configurable (from bndtools) but as it is based on > MetaTypeService, it can't help us toworatound the limitations. > >> This will for sure have an influence on other related specs like for example >> MetaType service or Declarative Services. > > Will? Maybe you takl about different "Configurable". Could you please > provide me a link to Peter's blog? (I've read > http://www.osgi.org/blog/2010/08/easier-configuration-admin.html, > http://www.osgi.org/blog/2011_03_01_archive.html, > http://www.osgi.org/blog/2010_08_01_archive.html already). Yes, that's that. > > I'll check also OSGi Alliance discussions. Yep, that would have been the next proposal ;-) Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
