Yes, but you can shorten it further: b.addModule( CommitLogModule.extend() .addListener( CommitListener.class ) .addListener( DictionaryListener.class ) .addListener( SearchIndexListener.class ) .addListener( PriceEventListener.class ) .module() );
Andrus > On May 29, 2017, at 6:38 PM, Hugi Thordarson <[email protected]> wrote: > > Is this correct module loading code for the New World Order? > > b.addModule( CommitLogModule.extend().addListener( CommitListener.class > ).module() ); > b.addModule( CommitLogModule.extend().addListener( DictionaryListener.class > ).module() ); > b.addModule( CommitLogModule.extend().addListener( SearchIndexListener.class > ).module() ); > b.addModule( CommitLogModule.extend().addListener( PriceEventListener.class > ).module() ); > > Cheers, > - hugi > > > >> On 29 May 2017, at 15:04, Andrus Adamchik <[email protected]> wrote: >> >> Just squeezed an 11th hour change before we freeze the Beta: >> >> https://github.com/apache/cayenne/commit/175ec07f69446ea89c8ed8ec338b29d45f95821e >> https://github.com/apache/cayenne/commit/ab6554dc6412dda640ebfcd6a4797cb0a1193f5f >> >> The goal is to eliminate a new API inconsistency. With the introduction of >> auto-lodable modules, classes that we used to call FooModuleBuilder no >> longer build a FooModule. The module is loaded automatically and can not be >> changed. The corresponding "builder" builds a separate custom module with >> extensions. This pattern is present in: >> >> 1. CommitLogModuleBuilder >> 2. CacheInvalidationModuleBuilder >> 3. CryptoModuleBuilder >> (4. OsgiModuleBuilder... if we make it auto-loadable) >> >> Instead of a builder there's now an "extender", which is otherwise analogous >> to the builder, and the invocation looks like this: >> >> Module extensions = >> CommitLogModule.extend().addListener(mockListener).module(); >> >> I changed #1, and if there are no objections will change #2 and #3. >> >> Andrus >> >
