Stefan, Yes, please open an enhancement request in JIRA.
IMO the 'overridable' attribute on <service-point> doesn't feel quite right. I think it is odd to declare a service point as overridable in one module while the default implementation is possibly declared in another module. Isn't this overridability really just a property of the implementation? So a different solution would be to move the 'overrideable' attribute to the implementation. In fact that does not quite work when the implementation is "inlined" into the <service-point> declaration. It would thus need to be declared for both <create-instance> and <invoke-factory>. Then the question arises if the 'type' attribute is still required? Also is 'final' maybe a better name for the attribute? --knut On 4/25/05, Liebig, Stefan <[EMAIL PROTECTED]> wrote: > 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 > > > --------------------------------------------------------------------- > 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]
