I made this change and its up for review. https://github.com/apache/incubator-fluo/pull/817
On Thu, Feb 23, 2017 at 5:36 PM, Keith Turner <[email protected]> wrote: > The current way observers are set up in Fluo requires specifying a > class for each observers in configuration. This is cumbersome and > prevents using lambdas and anonymous inner classes. It also makes it > hard to follow what a Fluo Application is doing. This cumbersome way > of setting things up propagates forward into higher level constructs > in Fluo Recipes making them also cumbersome to use. > > I think it would be much simpler if the user only had to specify one > factory class in configuration that created all observers. This > factory would be free to pair a lambda with a column for an observer. > Observed columns would no longer be tightly coupled with a specific > class. I am thinking the factory would look something like the > following. > > interface ObserversFactory { > Map<ObservedColumn, Observer> getObservers(SimpleConfiguration > applicationConfig); > } > > A user would implement this interface with a class that creates all of > their observers. > > class UserObserversFactory implements ObserversFactory { > Map<ObservedColumn, Observer> getObservers(SimpleConfiguration appConfig) { > //all of users observers are setup here in code, which is much > easier to follow than current way of configuring each observer class > individually. > HashMap observers = ...; > observers.put(col1, tx,row,col -> ....); //an observer that's a lambda > ExportQueue.addObserver(observers, appConfig, "queueId", exports > -> ....); //using a lambda to handle exports... > } > } > > The user would configure Fluo to use the above observer factory. > > I am thinking of trying to implement this for 1.1, but wanted to see > if anyone had any input before I started. If it seems to work well, I > was thinking of deprecating the current way of configuring observers. > I would update webindex and fluo recipes in parallel to evaluate the > changes.
