9 maj 2014 kl. 07:53 skrev Andreas Gies <andreas....@googlemail.com>:
> 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. The issue is that you cannot alter the configuration used by an ActorSystem while that system is running: in most cases this will not have an effect (since values are extracted only at system startup) or it will deeply confuse things. My conclusion so far has been that Akka and OSGi are fundamentally at odds with each other, precisely for the reason that you describe: the ActorSystem is foundational in a sense, but it depends on the Config which is only fully known at the highest level. What we offer is a way to implement a bundle in terms of an embedded ActorSystem and we can also expose ActorRefs from that bundle to be consumed by other bundles (and their contained actors, which possibly live in a different ActorSystem). This is composable in the fashion we discussed so far, given that you have to restart that whole part every time a configuration change occurs. So my takeaway from this discussion is that a modular Akka OSGi application will have to contain multiple ActorSystems. Regards, Roland > > 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 akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
