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

Reply via email to