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]
