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
