FW: Again: Overridable services

[Liebig, Stefan]

Title: FW: Again: Overridable services

An error?!


-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED]]
Sent: Thu 21.04.2005 20:01
To: hivemind-dev@jakarta.apache.org
Subject: RE: Again: Overridable services

There are other possible conflicts.  What if two implementations claim to be
the "default" implementation?

-----Original Message-----
From: Liebig, Stefan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 21, 2005 7:35 AM
To: hivemind-dev@jakarta.apache.org
Subject: Again: Overridable services


I 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 explain
was 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.0

I 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