Replace Spring config for CDX-server

[johnerikhalse]

By using Spring for configuration almost all non private methods inn all classes must be considered as part of the API. By replacing config with some other, more restricted mechanism, this is avoided. In the short term this is only doable for the CDX-server since the configuration options here are relatively few.

[kngenie]

Update: I haven't fully understood the intent of the change. So this is for user-configuration, and application assembly will be done with Spring. That makes sense! Disregard my comment below.

Although I'm sympathetic about pain with Spring-based configuration, but I'm not sure this is the right move. My thoughts are:

• Spring does not allow for calling methods - just configuring properties (I'm assuming "methods" is just a slip of finger). Concern of "being considered as part of the API" can be addressed with careful class design and documentation.
• With typesafe config, (apparently) we need to implement Settings object that does config validation, translation etc. While this sounds fine for configuring well-established set of parameters within particular deployment, It'd be painful to do for entire Wayback. Is typesafe language powerful enough to configure new type of index sources without much glue code? If we try to make typesafe config-based configuration powerful enough, we may find ourselves developing alternate syntax for Spring.
• Some deployment (yes, IA :-) utilizes Spring goodies like bean factory, MVC, etc. Spring is more than configuration mechanism. Probably typesafe config should be considered as the replacement of properties file, and used alongside Spring, so that only advanced deployment would require modification to Spring config.
• We're going to make a big change toward 3.0.0. It may be too early to work on a custom configuration syntax.