How
about this? A service point can be declared to be "overridable." The
"default" implementation would be any implementation that is contributed within
the same exact module (whether it's inline or in a separate implementation
block). If a service point is "overridable", other modules can contribute
an implementation to it and it will replace the "default" implementation if one
was provided.
-----Original Message-----
From: Liebig, Stefan [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 21, 2005 7:35 AM
To: [email protected]
Subject: Again: Overridable servicesI would like to discuss the current overriding solution for services (again).
I think that it is not sufficent, at least not for the use case that we have.A few time ago I posted an alternative approach for this problem, but the
response was very weak, except one consent. What I have missed to explainwas the motivation for the proposal. So here it is.Our use case is the following:
We are building a framework using HiveMind, the framework is used on both
client and server side and this framework is used by our customers. Our client
is a Java client that communicates via web services with the server.
There are client/server parts which are common and parts which are different.
However, we have services which are declared (not yet implemented) in the common
part and different implementations based on client/server side. So far this works
quite well. But know we have the requirement that our customers would like to
override our �default� implementations.
The current implementation of overidable services prevents that, because our
server/client implementation is already the �override�. But it should be the
default.The approach I posted a few weeks ago could solve this and by choosing the
appropriate default values for the new attributes, this proposal would be
compatible to hivemind 1.0. The current solution is not compatible to 1.0I simply attach here my first posting/proposal: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:
[EMAIL PROTECTED]: not requiered, ( true | false ), default value = false
[EMAIL PROTECTED]: not requiered, ( default | override ), default value = default[EMAIL PROTECTED] defines whether a service is overridable or not. Default
behaviour is like it is today, which is not overridable.
[EMAIL PROTECTED] 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
[EMAIL PROTECTED] is false. If [EMAIL PROTECTED] is true than the
�inlined� implementation is a default (overridable) implementation.Conflicts (HiveMind error):
[EMAIL PROTECTED] == false && [EMAIL PROTECTED] == override
are there any other possible conflicts?Stefan
