Hi, Thank you Clément. I just created the Jira issue: https://issues.apache.org/jira/browse/FELIX-2688
Regards, Olivier -----Message d'origine----- De : Clement Escoffier [mailto:[email protected]] Envoyé : lundi 8 novembre 2010 09:56 À : [email protected] Objet : Re: iPojo "requires.filters" Hi, On 08.11.2010, at 09:26, Bigard Olivier wrote: > Hi, > > First, thank you for your answer. > > I totally agree with your point regarding the name convention. > But what I propose is different. The idea is just to have an Array of > key/value pairs where keys are the identity of the dependencies and the > values are the filter of each dependency. This Array could be transformed > into a Dictionary object at the beginning of the "configure()" method of the > "DependencyHandler" class. > Imagine you have a class with following dependencies: > > @Requires(id="myFirstDep") > private A a; > @Requires(id=" mySecondDep ") > private B b; > > What I propose is to build the following property to inject in the instance: > > conf.put("requires.filters", new String[] {"myFirstDep", > "(property1=value1)", "mySecondDep", "(property2=value2)"}); Oh, I see. It looks a little bit weird, but fix the issue. > > And the transformation from the Array to the Dictionary could be: > > private Dictionary getRequiresFilters(Object requiresFiltersValue) > throws ConfigurationException > { > if (requiresFiltersValue != null && > requiresFiltersValue.getClass().isArray()) > { > String[] filtersArray = (String[]) requiresFiltersValue; > if (filtersArray.length % 2 != 0) > { > throw new ConfigurationException("A requirement filter is > invalid : " + requiresFiltersValue); > } > Dictionary requiresFilters = new Hashtable(); > for (int i = 0; i < filtersArray.length; i += 2) > { > requiresFilters.put(filtersArray[i], filtersArray[i+1]); > } > > return requiresFilters; > } > > return (Dictionary) requiresFiltersValue; > } > If you can open a jira issue and propose a patch, I would be happy to apply it. Regards, Clement > Concerning your proposal to use iPojo factories instead of ConfigAdmin: we > tested that and it's working perfectly, but we need to persist the > configuration (the "requires.filters" property but also all the configuration > properties of each instance) and by only using iPojo, it's not persisted. > We also tested the use of the API to update the filter, but this was the same > conclusion as previous point: no persistence. > This is why we need to use iPojo in combinaison with ConfigAdmin... > > Thanks and regards, > Olivier > > -----Message d'origine----- > De : Clement Escoffier [mailto:[email protected]] > Envoyé : dimanche 7 novembre 2010 13:57 > À : [email protected] > Objet : Re: iPojo "requires.filters" > > Hi, > > On 04.11.2010, at 12:55, Bigard Olivier wrote: > >> Hi, >> >> >> >> I tried to dynamically update the < filter > value of a < @Requires > >> annotation. >> >> The problem is that I'm using ConfigAdmin service to create my instances >> and, as Clement explained in the following thread, ConfigAdmin doesn't >> support Dictionary class... >> >> http://old.nabble.com/-iPOJO--Filter-as-a-parameter-to28927205.html >> >> >> >> Is there any reason why "DependencyHandler" class cannot analyze another >> structure than a Dictionary in the "configure()" method for >> "requires.filters"? >> >> Would it be possible to pass a Collection object in the properties >> Dictionary for "requires.filters" key and the "DependencyHandler" >> analyzes it like a suit of key/value pairs >> ({key1;value1;key2;value2;...})? > > The handler uses a dictionary / map because of of the dependency > identification. You can have several dependencies, and so update several > filters. The only way to support 'flat' structure would be to use name > convention, and I'm definitely not a fan of such kind of techniques. > > To update the filter you can either: > - use iPOJO factories instead of Config Admin. Factories support maps. > - use the iPOJO API to update the filter of a specific instance > > Regards, > > Clement > >> >> >> >> Thanks in advance >> >> Regards, >> >> Olivier >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
