I would phrase things slightly different "there's no runtime DI framework for Scala out the shelf “ => I don’t think that’s exactly true, some discussion is here: http://letitcrash.com/post/55958814293/akka-dependency-injection
But providing an SPI is different than adopting dependency injection in some ways - SPI is more of a code organization decision vs a binding approach. I am currently more concerned about the code organization, and if we want a more complex binding approach in the future (guice etc), that will certainly be possible. For example, what I proposed with akka-spi does not facilitate dependency injection EXCEPT for the impl choice of a specific SPI. If its not an SPI, it cannot be injected (unless through some other way). I’m not sure if that is a real problem, but I’m interested in feedback to find out. "need to agree on what gets packaged by default in the docker containers” => this is not really critical, other than streamlining the classpath (ignoring things like duplicate classes with different versions etc), since - regardless of the classpath, the active impl will have to be explicitly enabled (if you don’t want to use the default). - a default will always be available with the standard build(s) in short: no change to existing behavior We could start with 2 builds of each container: - includes only default SPI impls - includes default impls + all alternate impls (each SPI impl enabled via runtime flags e.g. whisk.spi.invoker=whisk.invoker.Reactive) And additional container variants would have to be custom builds (at least with build flags, or at most a separate gradle script), possibly with customized application.conf (to avoid runtime flags for enabling alternate SPI impls). I think an example will help, like DefaultInvoker vs InvokerReactive (a theoretical alternate impl to Invoker SPI): - docker run invoker:latest (runs invoker with default impl DefaultInvoker) - docker run invoker-all:latest (runs invoker with default impl DefaultInvoker; all impls are on classpath) - docker run invoker-all:latest -Dwhisk.spi.invoker=whisk.invoker.Reactive (runs invoker with InvokerReactive impl, all impls are on classpath) - docker run invoker-custom:latest (runs invoker with whatever impl is configured in custom application.conf) Tyson On Jun 13, 2017, at 1:31 PM, Dragos Dascalita Haut <ddas...@adobe.com.INVALID<mailto:ddas...@adobe.com.INVALID>> wrote: "...To make any progress on anything being pluggable, one approach is to provide a convention for doing the plugging...." So we're basically saying there's no runtime DI framework for Scala out the shelf and we need to come up with one ? It's fine if we do, but it would be great to list our assumptions on the things we're interested to support. i.e. do we want to factor in versioning with semantics for when 2 module versions are compatible, dependency chains, composition, etc. We also need to agree on what gets packaged by default in the docker containers for the controller and invoker, as this decision can make it easier or harder for users to switch implementations. Other than that, I +1 Tyson's idea which looks simple, easy to understand, and if it helps us initialize components dynamically, at runtime, it would be great to proceed with it sooner than later. There's also some thoughts and implementations into the Play Framework [1], but I'm not sure how adaptable those are for OW. dragos [1] - https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.playframework.com%2Fdocumentation%2F2.5.x%2FScalaDependencyInjection&data=02%7C01%7C%7C4b5d8175c091499de41e08d4b29b26ab%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636329826823508107&sdata=vRNiiadJluEX0fVcRr1R93XyREdIe522QwFr0LgDdJw%3D&reserved=0 ________________________________ From: Rodric Rabbah <rod...@gmail.com<mailto:rod...@gmail.com>> Sent: Friday, June 9, 2017 5:45:52 PM To: dev@openwhisk.apache.org<mailto:dev@openwhisk.apache.org> Subject: Re: Pluggable components in OpenWhisk Thanks for taking a shot at this! - at first glance it looks like this may be a good fit. I'll go through it more slowly to provide more informed feedback. -r
