feat: allow configurability of the middleware used by the HttpEventCollectorSender

[simonhege]

A user application can utilize HttpEventCollectorMiddleware to customize the behavior of sending events to Splunk. This can be configured by using the "middleware" configuration key

[simonhege]

I was more thinking that the class to be used has to be annotated with @RegisterForReflection. Especially on our side we plan to override this middleware config part of our deployment. Yes, possible classes are known at build time, but not the exact value of the middleware config parameter.

Do you suggest to use something like combinedIndex.getIndex().getAllKnownSubclasses(HttpSenderMiddleware.class) so that user does not care about using @RegisterForReflection?

[vietk]

I was more thinking that the class to be used has to be annotated with @RegisterForReflection. Especially on our side we plan to override this middleware config part of our deployment.

Yes it's a solution.

Yes, possible classes are known at build time, but not the exact value of the middleware config parameter.

I had the feeling that even the name of the middleware is known at build time, can you explain why it would be a runtime configuration?

Do you suggest to use something like combinedIndex.getIndex().getAllKnownSubclasses(HttpSenderMiddleware.class) so that user does not care about using @RegisterForReflection?

It could be a solution if we agree on point 2

[simonhege]

Yes, possible classes are known at build time, but not the exact value of the middleware config parameter.

I had the feeling that even the name of the middleware is known at build time, can you explain why it would be a runtime configuration?

In our CI/CD we aim at deploying same built version in every environment. Then step by step activate a change in one environment, then the other up to production. But we can accommodate this and handle this environment-specific activation inside the middleware we plan to use.

[vietk]

But we can accommodate this and handle this environment-specific activation inside the middleware we plan to use.

Fair enough, so let's try the solution proposed above

[vietk]

Fine for me.