Hi Roland, before I answer I should say that I haven't tested the approach you have suggested as of yet and therefore its more like a theoretical exercise for now. I'll try to explain the concern I have:
Most of my applications today are in retail space or within the airport industry (funny enough they seem to have similar integration requirements...). I have turned to OSGi about 5 years ago and my applications / bundles are typically designed in a way that allows in place updates. In other words, I might hot swap bundles and/or configuration and by using the appropriate OSGi API's I can usually figure out which bundles I need to restart. As you said that may have a cascading effect on the dependency of a bundle. Overall it is a very rare event that the complete container has to restart - usually that only happens once or twice a year. If I understood you correctly and try to think it through, the approach to have one omniscient bundle that collects the classpath's of all config contributing bundles gives me the impression that I would need to restart the ActorSystem, even if just a config contributing bundle has changed. With the more and more prominent role of the ActorSystem that would be pretty much a restart of my container. It is not necessarily a bad thing, its just different from what I have done so far. This having said, from an architecture perspective I would perceive the ActorSystem as the foundation with the config contributing bundles built on top. It feels a bit Un-OSGi if the change in a bundle built on top of something requires a restart of the thing it is built on. Within OSGi you find the ConfigAdmin service that allows users to change the configuration of bundles and allows "managed services" to track those changes and react accordingly. I was hoping to find something similar and hence my original question. What do think about this: - If I understand the Config API correctly (need to read it again - please forgive any errors) I can always look up configs with falling back to something else. - If I I were able to maintain a chain of fallbacks with the plain vanilla ActorSystem config as the last element I should be able to look any element in that chain. - To maintain that chain I could tap into the OSGi framework with some kind of extender pattern and inspect each bundle that is being loaded for the existence of a resource.conf file. I haven't fully designed nor implemented that but I think it should work. The caveat is that all my bundles have to be aware of that config override and probably couldn't rely on the original ActorSystem's config. I hope the above makes some sense Best regards Andreas Am Donnerstag, 8. Mai 2014 23:12:10 UTC+2 schrieb Akka Team: > > Hi Andreas, > > OSGi is an area where I am frequently learning new things, so you might > want to amend my world view: when you start an application, there will be > some bundle which depends on a bunch of other bundles to perform all its > functions, there will be transitive dependencies etc. What I had in mind > was that this bundle—which knows the universe—creates the > BundleDelegatingClassLoader and uses that to create the ActorSystem, which > should just make it work. Concretely, this bundle will know whether spray > is in the mix somewhere or not. In which scenarios would this scheme break > down? > > Regards, > > Roland > > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
