Redesign CompositeAccessPoint

[kngenie]

Toward 3.0.0 release, I'm thinking about redesigning CompositeAccessPoint family of classes. Perhaps Internet Archive is the only user of this class at this moment, because of its inflexibility. OpenWayback may want to move it to external (IA-owned) project, I wonder.

If we want to keep it in OpenWayback, I'd like to address some pain points with the framework:

• oracleUrl, staticExclusions: hard-coding specific combination of exclusion filters. already refactored to use CompositeAccessPoint.getExclusionFactory(). these deprecated members shall be dropped.
• AccessPointConfigs is just a wrapper around a HashMap<String, AccessPointConfig>, and getAccessPointConfigs() exposes that HashMap object (not Map). This makes it hard to implement dynamic loading of configuration, say, from external database. Define an better interface with richer functionalities.
• isProxyEnabled(): feels misplaced, because proxy/archival-url is not specific to CompositeAccessPoint. CompositeAccessPoint itself does not use this property.
• AccessPointAdapter.getSwitchCollPath(): feels misplaced. it simply returns ProxyAccessPoint.SWITCH_COLLECTION_PATH.
• AccessPointConfig.beanName: set through Spring's BeanNameAware interface, and used for storing collection identifier. It's unreliable because Spring sometimes modify bean name to ensure uniqueness. While it's nice to be able to write <bean name="collectionId" ..., it's only useful when you configure collections in Spring config. Rename the member, add setter/getter, and let setBeanName() update the member.
• findConfigForFile(String) method sounds too specific to particular deployment (=IA). Remove it from OpenWayback.

I'll update this description, as I find more. Inputs are welcome.

[kris-sigur]

One enhancement needed for them is a class level JavaDoc explaining the purpose of the classes.

Given how undocumented this part of OWB is, I'd be surprised if it's used outside IA.