On 11/10/11 4:04, [email protected] 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
