On Thu, May 7, 2009 at 12:46 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > ...On Wed, May 6, 2009 at 11:33 AM, Bertrand Delacretaz > <bdelacre...@apache.org> wrote: >> I'm trying to get an overview of the current issues related to >> customizing an embedded Jackrabbit repository using Sling bundles. > > Note that the current Jackrabbit configuration mechanism requires > direct access to all the *implementation* classes configured in the > repository.xml file. I'm not sure how this could best be made to work > with the cross-bundle class loading restrictions in an OSGi > environment...
One way that should work (didn't work before the recent upgrade of the Felix framework) is to provide the customization classes in fragment bundles that are attached to the jackrabbit server bundles. This makes those classes available to that bundle exactly as if they were part of the bundle. Another option is to use dynamic imports in the jackrabbit server bundle, and have the customization bundles export the implementation classes. Both the above solutions are suboptimal, but should allow Jackrabbit extensions to come from different bundles. I've had a look at https://issues.apache.org/jira/browse/JCR-1438 which is about using factories to instantiate the pluggable Jackrabbit components, and I'm wondering if a central customizing method would help, something like: interface Customizer { <T> getCustomizableComponentInstance( Class <T> componentType, Map<String, String> options } Where standard Jackrabbit would use Class.forName() based on a property in the options, and in an OSGi environment you'd plugin a Customizer that grabs the appropriate OSGi service based on the type T and options. Not sure if Jackrabbit requires Java 1.5 already, but it not the idea can also work without generics. -Bertrand
