polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Muhametsin <stanislav.muhamet...@zest.mail.kapsi.fi>
Subject Re: [Elastic Search] exception on startup
Date Tue, 09 Jun 2015 12:55:03 GMT
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.

Mime
View raw message