DI or Service Locator : Injecting implementations at run-time ( no static binding ) in scala

Question

i have a use case where i would like to offer a simple API to extend the functionality of my scala application.

i've spent the last couple of days trying to find a java/scala DI framework or library that does the following for me:

1. identifies implementations of an interface/trait on the classpath
2. instantiates and injects said implementations ( important feature: all of them ) at a site marked, preferably with an annotation
3. the above can't happen in the compiler because i need a plugin architecture where the plugins are not introduced until the JVM starts
4. therefore above can happen at JVM start (no hot-swap necessary)

i'm gravitating more and more towards OSGi DS, which i'm a big fan of, except i see it as an overkill due to #4.

i looked at guice, weld, scaladi and macwire, and could not immediately see a simple way to do this. My objective is for the "plugin" authors to not have to be aware of my injection/IoC solution in any way, except for the occasional Annotation ( preferably JSR330 ) At the injection site i am willing to deal with uglier things. :-)

Will i have to roll my own solution here, go with OSGi, or am i missing something trivial in the above mentioned libraries?

ps: i'm trying to steer clear of OSGi mainly because of it's interaction with the application framework i'm using (akka - not sure the bundle/DS lifecycle mixes well with a single actor system)

Answer 1

I have a look at what functionality is provided by Scaldi at the moment. I've found it is mature enough. So nothing hard to use this DI library to achieve your goals. For example you can only implement code for searching specifically annotated/specified in some configuration file or anything else.

Answer 2

If you like DS (and it seems eminently suitable for your problem) then why not solve any problems with Akka? I am pretty sure others will be willing to help out since it looks like an interesting combination.

Answer 3

If you can afford it, it's probably best (not only for you, but for the entire ecosystem) to go with Peter's suggestion.

Pragmatically speaking though, Java has SPI which comes OOTB and may be the simplest way to go in your particular case.