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
