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

[vietk]

I am bit sceptical this is gonna work with native compilation : The new instance of the middleware is done by reflection which is not supported by native image without the proper metadata: native image need to known all classes used at runtime otherwise it tries to remove every class definition not used int the final executable.

So we need to instrument the extension to retain the class definition, for that we need to produce a ReflectiveClassBuildItem from the LoggingSplunkProcessor: this might require a build time config which makes sense because the middleware is known at build time.
I would also provide a test in the integration-test package: we are performing native compilation there to test the extension.

[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.