Hi, yes, this is an unfinished area - the ResourceResolverFactory should have no ties to JCR and just use ResourceProvider services. So the basic idea is to create a new module for the implementation of the ResourceResolverFactory which has all the functionality that is not deferred to resource providers.
I think some time ago Felix was working on a prototype for this. Not sure what the status is. But that's definitely something we should do in Sling rather sooner than later. Regards Carsten 2012/2/1 Vidar Ramdal <vidar.ram...@webstep.no>: > I am experimenting with using Sling in a non-JCR application, that is, > I want to leverage Sling's templating support, OSGi goodies, resource > resolution etc, without using JCR, but in this case, a regular > relational database. I have created a ResourceProvider which turns DB > data into resources, so far so good. > > But I'd like to avoid any JCR dependency whatsoever. The changes > outlined in [1] did a lot to allow custom ResourceResolverFactories. > Still, much basic functionality happens in > JcrResourceResolverFactoryImpl that makes it hard to avoid, without > reimplementing: > . > - Domain mappings (o.a.s.jcr.resource.internal.helper.MapEntries, > MapEntry, Mapping) (JCR independant since SLING-1463 [2]) > - Redirect resouces (o.a.s.jcr.resource.internal.helper.RedirectResource) > - Resource iterator (o.a.s.jcr.resource.internal.helper.ResourceIterator) > - Star Resource (o.a.s.jcr.resource.internal.helper.starresource.StarResource) > - Resource provider resolution logic > (o.a.s.jcr.resource.internal.helper.ResourceProviderEntry) > - (maybe others) > > In fact, none of the classes listed above imports any packages from javax.jcr. > > So, if we accept that a non-JCR ResourceResolverFactory would have to > implement these features, shouldn't they be available somewhere > outside JcrResourceResolverFactoryImpl? > > I'm not sure what is the best approach - an > AbstractResourceResolverFactory, or turning these features into > separate components. > Any thoughts? > > > [1] > https://cwiki.apache.org/SLING/add-resourceresolverfactory-service-interface.html > [2] https://issues.apache.org/jira/browse/SLING-1463 > > -- > Vidar S. Ramdal <vidar.ram...@webstep.no> > Webstep AS - http://www.webstep.no > Besøksadresse: Lilleakerveien 8, 0283 Oslo > Postadresse: Postboks 272 Lilleaker, 0216 Oslo -- Carsten Ziegeler cziege...@apache.org
