On 9.6.2015 15:44, Niclas Hedhman wrote:
Yeah, and that is why I was putting it in a Config MODULE inside Infra
Layer... But Wait!! There is MORE !!!
a. ES Config is in the Config Module
b. On manipulation of that Configuration Entity Composite, the
StateNotificationConcern will locate all visible StateChangeListeners and
call them.
c. The ElasticSearchIndexer implements this and must either reside inside
the Storage Module, with Visibility.module, or if it has its own Indexing
Module (my case), the StateNotication will see it... BAM.
So!! Either Indexer need to be Visibility.module and inside the Storage
Module, OR the Configuration needs to be in its own Layer below.
Slightly off-topic and not helpful to the actual problem solving:
I remember stumbling upon this issue some years ago when I was still
actively using Java (and Qi4j).
I think the underlying problem is that Qi4j is coupling too tightly the
concepts of 'entity' and 'configuration composite'.
Thus basically forcing a pattern of having separate configuration layer
for any serious and big application.
This is not necessarily a bad idea in itself, a good application design
usually tends to put configuration stuff into its own, usually lowermost
layer.
Problem is, as your application becomes more complex to assemble (e.g.
the test case you are running), issues like this start to arise and are
very problematic to debug.
IMO for Qi4j/Zest 3.0, the whole configuration aspect should be
revisited and re-thought properly.
Especially new users are guaranteed to stumble on problems like this,
thus making adaptation of Qi4j/Zest really slow and troublesome.
