Hi Roland, thanks for your response. IMHO that sounds a bit un-OSGi. For example I am working on a family of applications, some of which have spray functionality, some which don't. If I understand you correctly, I would have to choose a different Classloader config for each container variant depending on which bundles may contribute to the configuration. If I were doing that, why not wrap up all those bundles in some uber-jar and include that in my container ?
What I am doing currently is to work with fallbacks quite frequently. My own bundles have their own configuration namespace. When I try to look up a config value i always try the bundle's config first and then fallback to the Actor Systems config. That works ok-ish except for the cases where other bundles (in my case spray) have more to contribute that wasn't available at actor system creation time. Therefore I was wondering if there was something more elegant. I guess I'll put my thinking cap on and experiment a bit, but certainly will keep the classloader suggestion in mind. Thanks and best regards Andreas Am Donnerstag, 8. Mai 2014 14:49:15 UTC+2 schrieb Akka Team: > > Hi Andreas, > > the mechanism we foresee for this case is that you create an appropriate > ClassLoader which has visibility into all the right bundles (e.g. using the > BundleDelegatingClassLoader from the akka-osgi package) and pass that to > the ActorSystem at creation. We have taken care that all reflective access > and configuration loading occur via that ClassLoader. > > Hooking into the OSGi configuration management facilities will be rather > painful because Akka does not support dynamic configuration: once the > ActorSystem is created you cannot change anything, so you would have to > restart the bundle that contains the ActorSystem upon every config change. > > Regards, > > Roland > > > > On Tue, May 6, 2014 at 11:50 AM, Andreas Gies > <[email protected]<javascript:> > > wrote: > >> Hello Hakkers, >> >> today I am interested how you usually configure your bundles inside an >> OSGi container. >> >> I can easily access the application.conf provided with Akka itself to get >> to all the default values. I can also provide bundle specific configuration >> in separate files and my bundle would pick up those. >> >> However, I have just done some experimenting with Spray in OSGi and the >> problem is as follows: >> >> Several spray bundles contain resource.conf files with default values >> that make sense to configure spray. On top of that the user has to provide >> some additional values to make his route work. >> The ActorSystem that lives in some bundle not knowing about spray does >> not see the resource.conf files provided by spray and the user-bundle >> should only contain the values it wishes to add or override. >> >> I have seen examples to do some classloader tweaking (e.g. [1]) to bring >> the resource.conf files into scope when the ActorSystem is initialized. >> From my (probably limited) understanding that would kind of defeat the >> purpose of OSGi. The ActorSystem shouldn't know about the bundles that are >> installed and may contribute to the configuration. My current solution is >> to replicate the spray settings in my bundle's conf file, but that somehow >> doesn't feel right either. >> >> I was wondering whether someone has thought about / tried to implement >> some kind of whiteboard pattern ? - I am thinking along the lines of an >> Akka config service that starts with the default application.conf. The >> extender would merge resource.conf files as akka bundles are installed >> remove the settings again when the bundle is uninstalled. Does the Config >> API provide such functionality ? >> >> Well, I just wanted to hear some thoughts before diving into such an >> extender .... >> >> >> [1] https://groups.google.com/forum/#!topic/spray-user/lmcdBsxNzdQ >> >> >> Thanks and best regards >> Andreas >> >> -- >> >>>>>>>>>> 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Akka Team > Typesafe - The software stack for applications that scale > Blog: letitcrash.com > Twitter: @akkateam > -- >>>>>>>>>> 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.
