You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by De...@imag.fr on 2011/11/10 10:04:11 UTC
iPojo "Service dependency Management"
Hi,
Related to the iPojo "Service Dependancy management"
Actually
Thanks to "requires.filters" property it is possible to override the
filter attribute for a <requires ..>.
Thanks to the policy attribute it is possible to define the binding
policy, but it not possible to override the attribut "policy".
Thanks to the "comparator" attribute it is possible to override the
default implementation for sorting a service provider.
IPojo manages the non-functionalies for requiring and 'aggregating' services.
But the cardinality (non functional propertie) is not managed, and
must be implemented by the "pojo".
What is your opinion to add/improve , features here after
i) The binding policy is overridable (taken eexample as requires.filters)
ii) The "requires" manages the cardinality , and the cardinality is
overridable too.
iii) Having the cardinality feature, the "Dynamic-priority" policy
would also be improved in order to respect the cardinality . This
would be proposed as a new attribute by example.
Best regards
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo "Service dependency Management"
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/10/11 4:04, Denis.Morand@imag.fr wrote:
> Hi,
>
> Related to the iPojo "Service Dependancy management"
>
>
> Actually
> Thanks to "requires.filters" property it is possible to override the
> filter attribute for a <requires ..>.
>
> Thanks to the policy attribute it is possible to define the binding
> policy, but it not possible to override the attribut "policy".
>
> Thanks to the "comparator" attribute it is possible to override the
> default implementation for sorting a service provider.
>
>
> IPojo manages the non-functionalies for requiring and 'aggregating'
> services.
> But the cardinality (non functional propertie) is not managed, and
> must be implemented by the "pojo".
>
> What is your opinion to add/improve , features here after
> i) The binding policy is overridable (taken eexample as
> requires.filters)
> ii) The "requires" manages the cardinality , and the cardinality is
> overridable too.
> iii) Having the cardinality feature, the "Dynamic-priority" policy
> would also be improved in order to respect the cardinality . This
> would be proposed as a new attribute by example.
I don't see how you can change a component's expected cardinality on a
required service. The component defines what it can handle (i.e.,
optional, one, or many), it is not possible for the management framework
to make these decisions.
However, in some cases it is ok to change them (e.g., making optional
become required or aggregate become singular), but these are only
because the result is a subset of the component's expressed dependency
characteristics.
So, unless I misunderstand what you are asking, I don't see how we can
allow cardinality to be externally managed.
-> richard
>
> Best regards
> Denis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo "Service dependency Management"
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/10/11 4:39, Denis.Morand@imag.fr wrote:
> Hi,
>
> Yes,
> A component requires (wants) only 2 services among n available.
> <requires .... cardinality="0..2" aggregate="true" ... >
Way back when we first started this in Service Binder, we thought about
whether or not it made sense to have other cardinalities, but never
could come up with use cases that made sense.
I'm still not convinced it make much sense, but it is certainly do-able.
I assume you mean that you'd take the first N in the sorted order, where
N is the cardinality value. What if N aren't available?
Personally, I think the use cases for this are fairly limited, so I
wouldn't be inclined to believe it is worth adding any extra complexity
to support this. You can definitely work around it in other ways.
-> richard
>
> Best Regards
> Denis
>
>
> Clement Escoffier <cl...@gmail.com> a écrit :
>
>> Hi,
>>
>> On 10.11.2011, at 10:04, Denis.Morand@imag.fr wrote:
>>
>>> Hi,
>>>
>>> Related to the iPojo "Service Dependancy management"
>>>
>>>
>>> Actually
>>> Thanks to "requires.filters" property it is possible to override the
>>> filter attribute for a <requires ..>.
>>>
>>> Thanks to the policy attribute it is possible to define the binding
>>> policy, but it not possible to override the attribut "policy".
>>>
>>> Thanks to the "comparator" attribute it is possible to override the
>>> default implementation for sorting a service provider.
>>>
>>>
>>> IPojo manages the non-functionalies for requiring and 'aggregating'
>>> services.
>>> But the cardinality (non functional propertie) is not managed, and
>>> must be implemented by the "pojo".
>>>
>>> What is your opinion to add/improve , features here after
>>> i) The binding policy is overridable (taken eexample as
>>> requires.filters)
>>
>> This can be tricky is you set the policy to 'static'. Indeed, that
>> would mean that whoever was already injected it must be frozen. If we
>> decide to 'reset' the set of injected services, then it should be ok.
>>
>>> ii) The "requires" manages the cardinality , and the cardinality is
>>> overridable too.
>>> iii) Having the cardinality feature, the "Dynamic-priority" policy
>>> would also be improved in order to respect the cardinality . This
>>> would be proposed as a new attribute by example.
>>
>> As Richard, I'm a bit lost here. Do you mean that a component can
>> specify it wants only 2 services (instead of n) ?
>>
>> Regards,
>>
>> Clement
>>
>>>
>>> Best regards
>>> Denis
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo "Service dependency Management"
Posted by De...@imag.fr.
From my "application" only a maximum is requested...
For sure , there will be an application that requests to process the minimum
Best Regards
Denis
Clement Escoffier <cl...@gmail.com> a écrit :
>
> On 10.11.2011, at 10:39, Denis.Morand@imag.fr wrote:
>
>> Hi,
>>
>> Yes,
>> A component requires (wants) only 2 services among n available.
>> <requires .... cardinality="0..2" aggregate="true" … >
>
> Does it also implies minimum, such as in "2..4", where the
> dependency is invalid if only one service is available ?
>
> Regards,
>
> Clement
>
>>
>> Best Regards
>> Denis
>>
>>
>> Clement Escoffier <cl...@gmail.com> a écrit :
>>
>>> Hi,
>>>
>>> On 10.11.2011, at 10:04, Denis.Morand@imag.fr wrote:
>>>
>>>> Hi,
>>>>
>>>> Related to the iPojo "Service Dependancy management"
>>>>
>>>>
>>>> Actually
>>>> Thanks to "requires.filters" property it is possible to override the
>>>> filter attribute for a <requires ..>.
>>>>
>>>> Thanks to the policy attribute it is possible to define the binding
>>>> policy, but it not possible to override the attribut "policy".
>>>>
>>>> Thanks to the "comparator" attribute it is possible to override the
>>>> default implementation for sorting a service provider.
>>>>
>>>>
>>>> IPojo manages the non-functionalies for requiring and
>>>> 'aggregating' services.
>>>> But the cardinality (non functional propertie) is not managed, and
>>>> must be implemented by the "pojo".
>>>>
>>>> What is your opinion to add/improve , features here after
>>>> i) The binding policy is overridable (taken eexample as requires.filters)
>>>
>>> This can be tricky is you set the policy to 'static'. Indeed, that
>>> would mean that whoever was already injected it must be frozen. If
>>> we decide to 'reset' the set of injected services, then it should
>>> be ok.
>>>
>>>> ii) The "requires" manages the cardinality , and the cardinality
>>>> is overridable too.
>>>> iii) Having the cardinality feature, the "Dynamic-priority"
>>>> policy would also be improved in order to respect the cardinality
>>>> . This would be proposed as a new attribute by example.
>>>
>>> As Richard, I'm a bit lost here. Do you mean that a component can
>>> specify it wants only 2 services (instead of n) ?
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>>>
>>>> Best regards
>>>> Denis
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo "Service dependency Management"
Posted by Clement Escoffier <cl...@gmail.com>.
On 10.11.2011, at 10:39, Denis.Morand@imag.fr wrote:
> Hi,
>
> Yes,
> A component requires (wants) only 2 services among n available.
> <requires .... cardinality="0..2" aggregate="true" … >
Does it also implies minimum, such as in "2..4", where the dependency is invalid if only one service is available ?
Regards,
Clement
>
> Best Regards
> Denis
>
>
> Clement Escoffier <cl...@gmail.com> a écrit :
>
>> Hi,
>>
>> On 10.11.2011, at 10:04, Denis.Morand@imag.fr wrote:
>>
>>> Hi,
>>>
>>> Related to the iPojo "Service Dependancy management"
>>>
>>>
>>> Actually
>>> Thanks to "requires.filters" property it is possible to override the
>>> filter attribute for a <requires ..>.
>>>
>>> Thanks to the policy attribute it is possible to define the binding
>>> policy, but it not possible to override the attribut "policy".
>>>
>>> Thanks to the "comparator" attribute it is possible to override the
>>> default implementation for sorting a service provider.
>>>
>>>
>>> IPojo manages the non-functionalies for requiring and 'aggregating' services.
>>> But the cardinality (non functional propertie) is not managed, and
>>> must be implemented by the "pojo".
>>>
>>> What is your opinion to add/improve , features here after
>>> i) The binding policy is overridable (taken eexample as requires.filters)
>>
>> This can be tricky is you set the policy to 'static'. Indeed, that would mean that whoever was already injected it must be frozen. If we decide to 'reset' the set of injected services, then it should be ok.
>>
>>> ii) The "requires" manages the cardinality , and the cardinality is overridable too.
>>> iii) Having the cardinality feature, the "Dynamic-priority" policy would also be improved in order to respect the cardinality . This would be proposed as a new attribute by example.
>>
>> As Richard, I'm a bit lost here. Do you mean that a component can specify it wants only 2 services (instead of n) ?
>>
>> Regards,
>>
>> Clement
>>
>>>
>>> Best regards
>>> Denis
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo "Service dependency Management"
Posted by De...@imag.fr.
Hi,
Yes,
A component requires (wants) only 2 services among n available.
<requires .... cardinality="0..2" aggregate="true" ... >
Best Regards
Denis
Clement Escoffier <cl...@gmail.com> a écrit :
> Hi,
>
> On 10.11.2011, at 10:04, Denis.Morand@imag.fr wrote:
>
>> Hi,
>>
>> Related to the iPojo "Service Dependancy management"
>>
>>
>> Actually
>> Thanks to "requires.filters" property it is possible to override the
>> filter attribute for a <requires ..>.
>>
>> Thanks to the policy attribute it is possible to define the binding
>> policy, but it not possible to override the attribut "policy".
>>
>> Thanks to the "comparator" attribute it is possible to override the
>> default implementation for sorting a service provider.
>>
>>
>> IPojo manages the non-functionalies for requiring and 'aggregating'
>> services.
>> But the cardinality (non functional propertie) is not managed, and
>> must be implemented by the "pojo".
>>
>> What is your opinion to add/improve , features here after
>> i) The binding policy is overridable (taken eexample as requires.filters)
>
> This can be tricky is you set the policy to 'static'. Indeed, that
> would mean that whoever was already injected it must be frozen. If
> we decide to 'reset' the set of injected services, then it should be
> ok.
>
>> ii) The "requires" manages the cardinality , and the cardinality is
>> overridable too.
>> iii) Having the cardinality feature, the "Dynamic-priority" policy
>> would also be improved in order to respect the cardinality . This
>> would be proposed as a new attribute by example.
>
> As Richard, I'm a bit lost here. Do you mean that a component can
> specify it wants only 2 services (instead of n) ?
>
> Regards,
>
> Clement
>
>>
>> Best regards
>> Denis
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: iPojo "Service dependency Management"
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 10.11.2011, at 10:04, Denis.Morand@imag.fr wrote:
> Hi,
>
> Related to the iPojo "Service Dependancy management"
>
>
> Actually
> Thanks to "requires.filters" property it is possible to override the
> filter attribute for a <requires ..>.
>
> Thanks to the policy attribute it is possible to define the binding
> policy, but it not possible to override the attribut "policy".
>
> Thanks to the "comparator" attribute it is possible to override the
> default implementation for sorting a service provider.
>
>
> IPojo manages the non-functionalies for requiring and 'aggregating' services.
> But the cardinality (non functional propertie) is not managed, and
> must be implemented by the "pojo".
>
> What is your opinion to add/improve , features here after
> i) The binding policy is overridable (taken eexample as requires.filters)
This can be tricky is you set the policy to 'static'. Indeed, that would mean that whoever was already injected it must be frozen. If we decide to 'reset' the set of injected services, then it should be ok.
> ii) The "requires" manages the cardinality , and the cardinality is overridable too.
> iii) Having the cardinality feature, the "Dynamic-priority" policy would also be improved in order to respect the cardinality . This would be proposed as a new attribute by example.
As Richard, I'm a bit lost here. Do you mean that a component can specify it wants only 2 services (instead of n) ?
Regards,
Clement
>
> Best regards
> Denis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org