Having a way to define "default" impls and have those easily overriden would be really useful. We've often needed to be able to do that and have clunky work arounds at various places to deal with not having any defaulting mechanism. But there are several other problems with the current discovery mechanism which it would be good to fix, some of them have already been mentioned in this thread, here's the list i can think of:
1) unable to define default impls and have an easy way to override the default 2) random startup order so intermittent fails when a service looks up another service during startup 4) how to choose when there are multiple impls 5) choose impls programaticaly at runtime so impls can enable/disable themselves based on the environment Before suggesting approaches on how to fix do we agree with that list of things to fix? ...ant On Tue, May 19, 2009 at 7:38 PM, Raymond Feng <[email protected]> wrote: > We have a lot of default implementations for the system services (for > example, all the model factories, processors and system utilities) and the > declarations of such services are not in a separate module which can be > removed. > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Tuesday, May 19, 2009 10:26 AM > To: <[email protected]> > Subject: Re: Supporting an optional ranking attribute for system services > >> I still think we need to understand a more complete picture. >> >> If its just to enable using different ContributionClassLoaderProvider >> impls then maybe ContributionClassLoaderProvider should just be in a >> separate module so it can be removed if someone wants to use their >> own. Would that solve this particular problem without needing the >> complications of a new ranking system? >> >> ...ant >> >> On Tue, May 19, 2009 at 5:58 PM, Raymond Feng <[email protected]> wrote: >>> >>> Hi, >>> >>> My original proposal is not only just for pluggable extensions which can >>> be >>> easily removed. The primary use case is for vendors to embed Tuscany and >>> replace some of the system functions. For example, we have the >>> ContributionClassLoaderProvider and Tuscany provides a default >>> implementation. If the vendor decides to override that, a new module will >>> be >>> added but the default one from Tuscany is still there. Now the one from >>> the >>> vendor has higher ranking and it will be the effective one. >>> We can potentially leverage the idea to control the ordering of the >>> module >>> activators and other extensions for a given extension point. >>> >>> The selection of a set of modules to form a Tuscany runtime is a >>> different >>> topic. We now have the feature/profile idea to group them. >>> >>> Thanks, >>> Raymond >>> >>> -------------------------------------------------- >>> From: "ant elder" <[email protected]> >>> Sent: Tuesday, May 19, 2009 9:13 AM >>> To: <[email protected]> >>> Subject: Re: Supporting an optional ranking attribute for system services >>> >>>> On Tue, May 19, 2009 at 4:54 PM, Raymond Feng <[email protected]> >>>> wrote: >>>>> >>>>> It's easy. The user can just add a "fragment" module that only contains >>>>> the >>>>> META-INF/services declarations. For example, if the default ranking for >>>>> Jetty is 1 and Tomcat is 2 and the user wants to use Jetty instead of >>>>> Tomcat, he/she can just add a new declaration for Jetty using ranking >>>>> 3. >>>>> >>>>> Thanks, >>>>> Raymond >>>>> >>>> >>>> Wouldn't it be (a lot) easier for the user to just remove the tomcat >>>> module? >>>> >>>> I think we need to step back a bit and all understand the use cases. >>>> We've currently got tuscany as lots of little modules so you can >>>> configure a system by choosing the modules you want to include, and >>>> working that way i'm not sure i see why we need a ranking mechanism. >>>> If we want to just include all the tuscany modules and then configure >>>> a runtime then explicitly configuring which modules to activate and >>>> the order they start may be easier and more flexible than a ranking >>>> system. And an explicit config file would also do what you need in the >>>> use case you're describing wouldn't it? >>>> >>>> ...ant >>> >>> >
