s/representaion/representation/

if the api is really internal, I think we can simplify this. Do we need to use a client here? Can we instead use the transport service directly? In that case we wouldn't need the RefreshAction, and the RefreshRequestBuilder. Otherwise the api ends up being exposed anyways, no matter if we say it's internal, but it doesn't have a corresponding REST handler, which makes things inconsistent.

agreed and this what I initially tried (like the shards exists internal api, See IndicesStore.java), but then I ran into cycle dependency issue with transport service.

ok...but client depends on the transport service anyway no? I think I don't get it

yes it does. all the ingest transport stuff gets instantiate with the the
action module and not with the node modules of the plugin. (See
IngestPlugin#onModule(ActionModule) ) So that is why the current approach
works.

On 4 December 2015 at 12:47, Luca Cavanna notifications@github.com wrote:

In
plugins/ingest/src/main/java/org/elasticsearch/plugin/ingest/PipelineStore.java
#15203 (comment)
:

     DeleteRequest deleteRequest = new DeleteRequest(request);
     deleteRequest.index(PipelineStore.INDEX);
     deleteRequest.type(PipelineStore.TYPE);
     deleteRequest.id(request.id());
     deleteRequest.refresh(true);

•    client().delete(deleteRequest, listener);
  

•    client().delete(deleteRequest, new ActionListener<DeleteResponse>() {
  

•        @Override
  

•        public void onResponse(DeleteResponse deleteResponse) {
  

•            client().execute(RefreshAction.INSTANCE, new RefreshRequest(), new ActionListener<RefreshResponse>() {
  

ok...but client depends on the transport service anyway no? I think I
don't get it

—
Reply to this email directly or view it on GitHub
https://github.com/elastic/elasticsearch/pull/15203/files#r46674077.

Met vriendelijke groet,

Martijn van Groningen

can we use == false

ok, will change.

sorry but we have to find other solutions for this than using these injection providers. We can't sustain this kind of software engineering here.

This one is easy. Can make this an inner class of PipelineStore and then there isn't a cyclic dependency.

why is shit guice exposed at all? Can't we reduce the number of @Inject here please it's such a pain to unwire all of this. Can we simply remove the @Inject and all the wiring and to in PipelineStoreBootstrapper

ReloadPipelinesAction action = new ReloadPipelinesAction(settings, pipelineStore, clusterService, transportService);

we can go even further and also don't wire PipelineStore and just call new in the bootstrapper as well.

so the reason pipeline store instance is managed by Guice is that the transport action classes uses it as a dependency. But that shouldn't be a problem, because if the store is exposed as a getter and the transport action classes depend on PipelineStoreBootstrapper then the constructor of the transport action classes can use this getter.