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 <and...@objectstyle.org> 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 >
