Bring dspace-oai Spring configuration / service handling in line with other modules

[kshepherd]

While trying to find a good way to use a mock OAI Solr core for integration testing, I realised how differently the dspace-oai module uses spring compared to other modules. Something that seemed like it should be relatively simple (define a mock OAI solr core/service in solr-services.xml which will be autowired in place of the usual http service) ended up getting quite tricky to pull apart and plan.

See: org.dspace.app.xoai.BasicConfiguration, the resolvers, and usage in other classes.

This issue might be closely related to #8112 (dependency injection issues)
cc: @mwoodiupui

Solutions?
I wanted to open this ticket to discuss possible solutions... I think a refactor to bring dspace-oai closer to how the rest of the codebase works will make things easier for developers in general.

• Application context (See dspace-oai can't inject dependencies from dspace-api #8112) - remove this idea entirely?
• Load the BasicConfiguration info needed to run core OAI services from spring XML instead of a compiled class
• Refactor code to use a Solr Service like discovery, statistics, authority and get rid of the 'Solr Resolver'
• There are likely other things that can be moved to beans defined / referenced in XML and simplify configuration loading in the dspace-oai endpoint code
• Anything else?

[mwoodiupui]

Much of this sounds like the way I wanted to address #8112. I've long thought that "configuration classes" are a weird notion anyway, and here this makes it a lot harder to do simple normal things. +1