A core architecture pattern of the εοs-toolkit is exchangeability of the main services. Many interfaces and classes are supported thru or by the factory design pattern. The constructed service also embeds such services. At this time of writing 13 services are defined. Additionally 10 parameters are configurable.

The embeded use of services makes the configuration very flexible. But it makes the configuration also complex to see through what's possible. First idea for a solution is to describe the possible configuration and paramter in the javadoc. I think this is a bad pattern. The javadoc description is not machine readable. The second and most common solution (my observation) is a description in an external descriptor - like an XML application. An XML application is machine readable but I think it's also not a well designed solution. The external descriptor may get out of sync with the implementation - the developer may forget to update the external resource of the service or configurable artefact.

For the eos-toolkit I'll try out a solution with metadata annotations in the concrete Java code artifact. A factory may annotated with a Factory annotation. A required parameter must be the name of the configuration key to store the classname of the implementation. An optional element may the name of the default implementation. Another annotation-type will describe the internally used services and possible configurations with there default value.

This solution is simple machine readable thru Javas reflection API and closed to the original artifact. Errors thru forgotten documenation may be fewer.

Why not use a dependency injection framework?

In my opinion Googles Guice and other dependency injection frameworks are not designed for fast recombination and configuration. But fast reconfiguration and recombination is one of the main opportunities in search engine solutions on semi- or unstructured data.