felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Extending Metatype
Date Fri, 03 Feb 2012 14:06:43 GMT

Am 03.02.2012 um 15:02 schrieb Martin Ždila:

> Hi Felix
> On Fri, Feb 3, 2012 at 2:11 PM, Felix Meschberger <fmeschbe@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 ;-)

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message