atom feed10 messages in org.apache.incubator.sling-devRe: The beast that is JcrResourceReso...
FromSent OnAttachments
Vidar RamdalFeb 1, 2012 1:37 am 
Carsten ZiegelerFeb 1, 2012 6:39 am 
Vidar RamdalFeb 1, 2012 11:25 am 
Carsten ZiegelerFeb 2, 2012 12:02 am 
Felix MeschbergerFeb 2, 2012 2:47 am 
Vidar RamdalFeb 2, 2012 4:31 am 
Vidar RamdalFeb 2, 2012 5:26 am 
Felix MeschbergerFeb 2, 2012 5:41 am 
Jeff YoungFeb 2, 2012 5:48 am 
Felix MeschbergerFeb 2, 2012 5:50 am 
Subject:Re: The beast that is JcrResourceResolverFactoryImpl
From:Vidar Ramdal (vida@webstep.no)
Date:Feb 1, 2012 11:25:35 am
List:org.apache.incubator.sling-dev

2012/2/1 Vidar Ramdal <vida@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

2012/2/1 Carsten Ziegeler <czie@apache.org>:

yes, this is an unfinished area - the ResourceResolverFactory should have no ties to JCR and just use ResourceProvider services.

Great, that's what I thought.

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.

By "all the functionality that is not deferred to resource providers", do you mean for instance those bullets I posted above (domain mappings etc)?

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.

I'd be interested in seeing this come to Sling, and could start do to some work on it - at least slowly, piece by piece. If we could find any references to Felix' prototype, I could start from there.