Just a guess - it looks like that you are trying to create a index with a
name that is already existing.
Possible solutions are :
- check if the index is already created
- delete the file-based storage (this approach is used in the unit tests)
- Use each time a new name
What is the context of
hmm, first time run ? Thats indeed strange..
ok, if you want I can take a look on the ES issue since I spend sometime on
this indexer..
cheers,
jj
2015-06-09 13:55 GMT+02:00 Niclas Hedhman nic...@hedhman.org:
Well, how can there be an existing Index the first time it is run?
Remember, I am
That second one is probably a consequence of the first problem, as the
client=null at passivation...
On Tue, Jun 9, 2015 at 7:55 PM, Niclas Hedhman nic...@hedhman.org wrote:
Well, how can there be an existing Index the first time it is run?
Remember, I am not using ES directly, only that the
Well, how can there be an existing Index the first time it is run?
Remember, I am not using ES directly, only that the ES extension attaches
itself to the EntityStateListener notification...
Just now, I go another problem, so I suspect that I am missing some crucial
setup/assembly part. Perhaps I
Paul (since you wrote this once upon a time),
I get an exception every time the Elastic Search Extension is loaded, even
if I wipe the $HOME/Library/Application Support/myapp where it seems that
ES extension is using (oh, yeah I am using the file system store)
Any ideas? Is it expected?
Caused
Ok, the reason is found... The most typical of problems...
The Configuration object of the ES extension triggers the
StateChangeNotification back to the ElasticSearch extension, which isn't
ready to process it yet.
Was this the reason why we always need a Configuration Layer, and a Config
Module
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
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
The concept of having Configuration as Entities was a great thing, IMHO,
and we shouldn't toss that out because of this issue at the configuration
of the stuff that handles the configuration-part.
But, maybe a separate mechanism should be used specifically for
EntityStores and Indexing
