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 > >
