Hi, Richard S. Hall schrieb: > On 9/16/09 13:55, Karl Pauls wrote: >> On Wed, Sep 16, 2009 at 1:31 PM, Felix >> Meschberger<fmesc...@gmail.com> wrote: >> >>> Hi, >>> >>> What's the community opinion on this wish ? >>> >>> It breaks specification compliance but in some cases it is useful. >>> >>> It may cause users for Felix configadmin to not work as expected with >>> other implementations of the Configuration Admin spec. >>> >>> It will not work together with MetaType because MetaType does not >>> support nested structures and Map. >>> >>> WDYT ? >>> >> I don't really like extensions if they are not compatible with the >> spec. That kind of stuff only leads to trouble later when other people >> adopt it without being aware that it ties them to a specific >> implementation. Is there no other way to make this work without >> breaking spec compliance? >> > > I have no issues with extensions as long as they are clearly separated > out somehow. For example, if you can only access them via some > FelixConfigAdmin service interface, so that bundles requiring the > behavior have an explicit dependency on it. It would be very bad news if > they only had a dependency on CM, but expected non-spec behavior.
Very good point, and now it gets interesting ;-) We need a FelixConfigurationAdmin able to provide FelixConfiguration supporting extended values. And then we need FelixManagedService and FelixManagedServiceFactory able to receive FelixConfiguration.... I am not really sure, whether I want to do this .... Regards Felix > > -> richard > >> regards, >> >> Karl >> >> >>> Regards >>> Felix >>> >>> Bulat Nigmatullin (JIRA) schrieb: >>> >>>> Make CM allow hierarchical values >>>> --------------------------------- >>>> >>>> Key: FELIX-1603 >>>> URL: https://issues.apache.org/jira/browse/FELIX-1603 >>>> Project: Felix >>>> Issue Type: Wish >>>> Components: Configuration Admin >>>> Reporter: Bulat Nigmatullin >>>> Priority: Minor >>>> >>>> >>>> We need some extended features in ConfigurationAdmin: submaps in >>>> configuration dictionaries, which will be read by my >>>> PersistenceManager. I have idea, how to do it: >>>> >>>> Create an interface: >>>> >>>> interface ConfigurationDictionary extends Dictionary { >>>> public ConfigurationDictionary copy(boolean deepCopy); >>>> } >>>> >>>> Lets CaseInsenstiveDictionary implements it: >>>> >>>> public ConfigurationDictionary copy(boolean deepCopy) { >>>> return new CaseInsensitveDictionary(this, deepCopy); >>>> } >>>> >>>> And rewrite some members ConfigurationImpl: >>>> >>>> private volatile ConfigurationDictionary properties; >>>> >>>> ... >>>> >>>> public Dictionary getProperties( boolean deepCopy ) >>>> { >>>> // no properties yet >>>> if ( properties == null ) >>>> { >>>> return null; >>>> } >>>> >>>> ConfigurationDictionary props = properties.copy( deepCopy ); >>>> >>>> // fix special properties (pid, factory PID, bundle location) >>>> setAutoProperties( props, false ); >>>> >>>> return props; >>>> } >>>> >>>> ... >>>> >>>> private void configure( final Dictionary properties ) >>>> { >>>> final ConfigurationDictionary newProperties; >>>> if ( properties == null ) >>>> { >>>> newProperties = null; >>>> } >>>> else >>>> { >>>> // remove predefined properties >>>> clearAutoProperties( properties ); >>>> >>>> // ensure ConfigurationDictionary >>>> if ( properties instanceof ConfigurationDictionary ) >>>> { >>>> newProperties = ( ConfigurationDictionary ) properties; >>>> } >>>> else >>>> { >>>> newProperties = new CaseInsensitiveDictionary( >>>> properties ); >>>> } >>>> } >>>> >>>> synchronized ( this ) >>>> { >>>> this.properties = newProperties; >>>> this.lastModificationTime = System.currentTimeMillis(); >>>> } >>>> } >>>> >>>> After this changes we will have possibility to create complex >>>> structures of properties. For example, nested maps or somesing else >>>> - depends on developer's wishes. >>>> >>>> Or, if it is not possible, just add nested maps in >>>> CaseInsensitiveDictionary implementation. But it will involve much >>>> more code changes. >>>> >>>> >>>> >>> >> >> >> >
