New AbstractSlingRepositoryManager base class (SLING-3384)

[Felix Meschberger <fm...@adobe.com>]

Hi all

After a few years living with the AbstractSlingRepository base class, I though it would be about time for a simpler reimplementation to get rid of a few restrictions:

  - External repositories (see below)
  - Repository polling (see below)
  - Dependency on Declarative Services
  - Complex setup of ServiceFactory

By introducing the new AbstractSlingRepositoryManager I was able to separate the actual OSGi service instance from the singleton repository. This makes the implementation as well as the extension a lot simpler: Basically it is a single method in the AbstractSlingRepository2 class and basically repository creation and shutdown in the AbstractSlingRepositoryManager class.

This is also the time to get rid of one of the more complex parts of the AbstractsSlingRepository: External repository access and repository pinging. We have added both in early times of Sling, where we expected the repository to be available outside of Sling, e.g. in a different Web Application accessible through JNDI or even in an external system accessible through RMI or such. While there may well be setups leveraging these features, I would expect most deployments to use an embedded repository instance. Hence external repository access and repository pinging (to solve the non-existing livecycle support in LDAP and RMI setups) don't belong into this abstract base class. Rather they should be implemented in specialized bundles such as the Sling Jackrabbit Client bundle (in contrib).

For now I have adapted the Jackrabbit Server and Oak Server bundle along with the Repository IT tests and the tests seem to run smoothly — except that on my box, the integration tests seem to block on the VanityPathTest

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-3384