Having to consider even more alternative implementations does indeed make the problem more complex. I don't see how we could address this kind of situation with an "overridable" attribute on the <implementation> element. I suspect that this is also a rather unusual setup and wonder if not the "conditional contribution" feature in HiveMind 1.1 (see http://jakarta.apache.org/hivemind/current/conditional.html) is a good enough solution.
Maybe conditional expressions in the "if" attribute on the <implementation> element is even good enough for the simpler situations with a single override implementation. What do you think? I can see that it could be useful to extend the conditional expression syntax with a "symbol" keyword to make the descriptors more "self contained". Then you could maybe do something like this: <module id="foo" version="1.0.0"> <service-point id="foo" interface="Foo"/> </module> <module id="default" version="1.0.0"> <implementation service-id="foo.foo" if="not symbol default.foo.foo.override"> <.../> </implementation> </module> <module id="override" version="1.0.0"> <contribution configuration-id="hivemind.ApplicationDefaults"> <default symbol="default.foo.foo.override" value="true"/> </contribution> <implementation service-id="foo.foo"> <.../> </implementation> </module> In this example the module with the default implementation of service "foo.foo" provides the symbol "default.foo.foo.override" as a hook for other modules to opt out the provided implementation. --knut On 4/26/05, Luke Blanshard <[EMAIL PROTECTED]> wrote: > Just when you guys have gotten on the same page, let me inject another > variable. > > Suppose you have a service with several implementations available. > Let's say that one is the default one, (which is not final), and there > are two others. How do you choose which one to use? > > Before you say "just don't do that", suppose that each of these other > two belongs to a different module, and that you require other services > from both modules. > > I suggest that there should be a way to explicitly select one of the > available implementations via symbols or some other built-in > configuration point. I don't know what the precise solution should be, > but I think we need one. > > Luke > > Liebig, Stefan wrote: > > > Knut, > > > > now I think I got what you mean! > > > > You are using �default� (either �final� or �non-final�) to describe > > the intention > > of the provider/developer of a service. His choices for a service > > could be: > > - default, non-final => this may be overriden > > - default, final => this can not be overriden > > - default, open (no implementation) => "could someone please implement > > this!" > > > > While our discussion I dropped this �intention� which I had in mind with > > my first proposal (the �overridable� attribute within service-point) and > > assumed that final and non-final could be sufficent. > > The above intentions could than be expressed as: > > - this may be overriden => non-final implementation > > - this can not be overriden => final implementation (this is > > what discomfits you, right?) > > > > Do you have a proposal (without any same-module magic) in mind, which > > would solve > > this problem? > > > > > > ------------------------------------------------------------------------ > > *Von:* Knut Wannheden [mailto:[EMAIL PROTECTED] > > *Gesendet:* Di 26.04.2005 09:21 > > *An:* [email protected] > > *Betreff:* Re: Again: Overridable services > > > > Stefan, > > > > > Knut, you were talking about a > > > > > > > Let's now consider a different usecase. You again have one module > > > > declaring the service point, a second module with a final > > > > (non-overridable) default implementation and a third module providing > > > > > > final default implementation. This is contradictory for me. > > > > > > > I think we don't agree on what we mean by default. The way I see it > > the default implementation is provided by the same developer(s) who > > specified the service point. This default implementation can either be > > overridable (i.e. non-final) or non-overridable (i.e. final). Thus I > > was talking about a final default implementation. Makes sense? > > > > > I just see two terms, which have the following equivalent > > > - final <=> type == override (from my first proposal) > > > - non-final <=> type == default (from my first proposal) > > > > > > > I don't quite agree. Does not an override only make sense in the > > presence of a default? Then how does one declare the default > > implementation as non-overridable? > > > > > Having two implementations A and B for a service point and both > > > are given, the following should be true: > > > > > > impl A final non-final > > > impl B > > > final error B wins > > > non-final A wins error > > > > > > In the case that there is just one implementation give, it will > > > �win� independent on the value of the final attribute. > > > > > > > I certainly agree with this. Selecting the "correct" implementation is > > trivial, but there is no way for HiveMind to know which implementation > > was the intended default. Thus it would be difficult to log a > > meaningful warning. The best HiveMind could do is to guess that the > > implementation in the same module as the service point (if there is > > one) is the default. > > > > --knut > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
