> On Oct 30, 2018, at 2:09 PM, Hosom, Stephen M <ho...@battelle.org> wrote: > > I bumped into a limitation that was a little frustrating to work around with > the config framework. > > > It is inconvenient that values stored in files read by adding to > Config::config_files are not available within the bro_init event. After > reviewing how the Config framework works, I understand why this is the case, > but it means that if you want to use configuration values on startup, you're > not guaranteed to be working with the anticipated value. > > > I think the introduction of an event that ensures that configuration files > have been read by the time that the event fires might be worthwhile. I was > wondering if anyone had any thoughts on how to resolve/work-around this issue.
This is an issue, but probably not the one you are thinking of. even if configuration files were fully read by the time bro_init was ran, you'd still need to handle the value changing at runtime. If you need to run code when an option changes, you can use the Option::set_change_handler to make bro raise an event. Using this instead of bro_init would fix the startup problem, and handle it changing at any time. There's a test that uses this in testing/btest/core/option-priorities.bro and a few other files. — Justin Azoff _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
