The resolutions of
SAK-10057 and
SAK-11347 demonstrated two approaches to support of optional "service provider" components which could be safely deployed as inactive binaries, possibly with a default implementation, and then selected (and made active) at runtime via a local "sakai.properties" file:
1) Define the service as a proxy around a target implementation ID.
2) Define a settable ID property in a central "provider selector" (e.g., UserDirectoryService's "providerName").
However, these only assume configuration specifications consisting of property strings, and only take care of on-or-off configuration. To allow for production deployment of binary service implementations which integrate with complex systems such as LDAP, we also need to support no-compile configuration of attribute-to-property maps and other more complex objects.
Any beans _defined_ by "sakai-configuration.xml" should refer only to Java classes available at the "shared" level of classloading. That is, the "class" attribute of the bean definition should be standard JDK, or a Spring kernel class, or a domain model class deployed as part of a "shared/lib" API.