Could we go a step further and have Loader be a standalone DS component which just references SlingRepository? And then move it to jcr.contentloader?
There doesn't appear to be a reason for depending upon the concrete class AbstractSlingRepository instead of the SlingRepository interface. I think there might have been pre-Jackrabbit 2, but there isn't now. Justin On 6/7/10 9:46 AM, Felix Meschberger wrote: > Hi all, > > I am looking at a strange situation starting Sling Trunk build. Not all > namespace prefixes seem to be registered in the Loader class of the JCR > Base bundle. > > IMHO the setup in the JCR Base Bundle between the > AbstractSlingRepository and the Loader is not optimal: > > * AbstractSlingRepository implements SynchronousBundleListener > to just forward the events to the Loader > * There is a time gap between the time the Loader class is > instantiated (and handling a set of bundles) and the time > AbstractSlingRepository is registered as a bundle listener > * There is a bug in the Loader constructor preventing all > just INSTALLED bundles from being registered by the BundleListener > only handles the INSTALLED (and UNINSTALLED and UPDATED) events. > > The last part will certainly miss some bundles. > > I suggest we change this setup such, that the Loader itself is the > bundle listener handles the events itself. The AbstractSlingRepository > just sets up the loader and uses it. > > See patch in SLING-1548. > > WDYT ? > > Regards > Felix > > [1] https://issues.apache.org/jira/browse/SLING-1548
