How to proceed? Shall I make a �feature� request for this in JIRA? ________________________________
Von: James Carman [mailto:[EMAIL PROTECTED] Gesendet: Do 21.04.2005 20:51 An: [email protected] Betreff: RE: Again: Overridable services Yeah, that sounds about right. I guess it would be better to allow there to be "default" implementations defined outside the scope of the declaring module for the service point. -----Original Message----- From: Liebig, Stefan [mailto:[EMAIL PROTECTED] Sent: Thursday, April 21, 2005 2:49 PM To: [email protected] Subject: FW: Again: Overridable services An error?! -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thu 21.04.2005 20:01 To: [email protected] 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: [email protected] 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
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
