What would be nice if this "just worked" for users who add their own extension impls without the user needing to do anything special.
As an example, we've the host-jms-asf module that users need to include a dependency on if they want to use tuscany JMS services, or if they want to have their own jms host they need to exclude host-jms-asf and add their own new module. It would be much nicer if Tuscany just used host-jms-asf by default if nothing else was provided, but if there was another jms host available then the other one would be used over the default host-jms-asf one. One way that could work is if a system service impl class name starts with "Default" then its always replaced if there's another class registered, and that seems quite simple and easy to understand. A problem with the ranking approach is that it doesn't seem obvious what a ranking means without knowing all the other rankings - eg, if my new host-jms-foo module uses a ranking of 423 will it be used? Same issue with the start sequence, it would be simple and obvious if there as some file that explicitly listed the services that must be started before others, but that start sequence is hard to see just by looking at individual ranking values. ...ant On Thu, May 21, 2009 at 4:45 PM, Raymond Feng <[email protected]> wrote: > +1 on 1). > +1 on 2). If all the system services are declarative, then "lookup" should > be fine without any ordering. I understand we have some extension points or > extensions are added programmatically by the module activators. A good > example is that all the module activators should be started by the ranking > and stopped by the reverse order. > +1 on 4). Removing "duplicate" modules is not always intuitive if a user > download an all-in-one distribution. It would be nice if they can co-exist > and Tuscany runtime will pick one by some means (such as ranking or some > kind of filter) > 5): OSGi has the "filter" concept when a service is looked up from the > registry. By default it selects the one with highest ranking. Do you have a > good use case how Tuscany would require that? > > Thanks, > Raymond > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Thursday, May 21, 2009 12:14 AM > To: <[email protected]> > Subject: Re: Supporting an optional ranking attribute for system services > >> On Thu, May 21, 2009 at 8:01 AM, Simon Laws <[email protected]> >> wrote: >>> >>> On Thu, May 21, 2009 at 6:04 AM, ant elder <[email protected]> wrote: >>>> >>>> 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 >>>> >>> >>> I think 1 and 4 (what was 3?) are the same issue. Not sure about 5. >>> Sounds like a solution. I would prioritize as follows because 2 keeps >>> hurting us. >>> >>> 2) random startup order so intermittent fails when a service looks up >>> another service during startup >>> 1) unable to define default impls and have an easy way to override the >>> default >>> >>> Simon >>> >> >> Not sure what happened to (3) and just now I can't think what it might >> have been :) I'll reply back if i think of it. >> >> I had (1) and (4) separate because i think they're subtly different, >> and I'm not totaly convinced yet that we really need much for (4) if >> we have (1). For (1) a default impl would be included within the >> tuscany base runtime and it should be easy for a user to add their own >> jar on top of the base runtime and have the impl picked up from there >> to override the default. For (4) its the user has included multiple >> jars containing impls for the same system service on top of the base >> runtime, thats the host-jetty/host-tomcat scenario and the simplest >> fix seems to be just delete one of the jars, so if we have (1) then do >> we really need to implement anything for (4). >> >> ...ant > >
