You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by "Liebig, Stefan " <St...@compeople.de> on 2005/02/22 15:50:51 UTC
Overridable service implementations
We have quite often the case that we would like to have a default implementation
for a service, which should be overridable by the users of our framework. The
possibility to achieve that by using the application/factory defaults is not very
obvious and hides this semantic because it can also be used for many other things.
Could we not add two attributes to the existing service point/implementation elements
to support this? Such as:
<service-point id=".." .. overridable="true"/>
<implementation service-id=".." type="default"/>
<implementation service-id=".." type="override"/>
With:
service-point@overridable <ma...@override> : not requiered, ( true | false ), default value = false
implementation@type: not requiered, ( default | override ), default value = default
service-point@overridable <ma...@override> defines whether a service is overridable or not. Default
behaviour is like it is today, which is not overridable.
implementation@type defines whether the implementation is a default implementation
or the overriden implementation. Default is ´default´, so that the behaviour is as
today.
An ´inlined´ implementation is a final (not overridable) implementation if
service-point@overridable <ma...@override> is false. If service-point@overridable <ma...@override> is true than the
´inlined´ implementation is a default (overridable) implementation.
Possible conflicts (hivemind errors/warnings):
service-point@overridable <ma...@override> == false && implementation@type == override
more ?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Overridable service implementations
Posted by Knut Wannheden <kn...@gmail.com>.
Stefan,
With HiveMind 1.1 this will be much easier. See
http://jakarta.apache.org/hivemind/current/override.html.
Regards,
--knut
On Tue, 22 Feb 2005 06:50:51 -0800, Liebig, Stefan
<St...@compeople.de> wrote:
> We have quite often the case that we would like to have a default implementation
> for a service, which should be overridable by the users of our framework. The
> possibility to achieve that by using the application/factory defaults is not very
> obvious and hides this semantic because it can also be used for many other things.
>
> Could we not add two attributes to the existing service point/implementation elements
> to support this? Such as:
>
> <service-point id=".." .. overridable="true"/>
> <implementation service-id=".." type="default"/>
> <implementation service-id=".." type="override"/>
>
> With:
> service-point@overridable <ma...@override> : not requiered, ( true | false ), default value = false
> implementation@type: not requiered, ( default | override ), default value = default
> service-point@overridable <ma...@override> defines whether a service is overridable or not. Default
> behaviour is like it is today, which is not overridable.
> implementation@type defines whether the implementation is a default implementation
> or the overriden implementation. Default is ´default´, so that the behaviour is as
> today.
>
> An ´inlined´ implementation is a final (not overridable) implementation if
> service-point@overridable <ma...@override> is false. If service-point@overridable <ma...@override> is true than the
> ´inlined´ implementation is a default (overridable) implementation.
>
> Possible conflicts (hivemind errors/warnings):
> service-point@overridable <ma...@override> == false && implementation@type == override
> more ?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org