|Vidar Ramdal||Feb 1, 2012 1:37 am|
|Carsten Ziegeler||Feb 1, 2012 6:39 am|
|Vidar Ramdal||Feb 1, 2012 11:25 am|
|Carsten Ziegeler||Feb 2, 2012 12:02 am|
|Felix Meschberger||Feb 2, 2012 2:47 am|
|Vidar Ramdal||Feb 2, 2012 4:31 am|
|Vidar Ramdal||Feb 2, 2012 5:26 am|
|Felix Meschberger||Feb 2, 2012 5:41 am|
|Jeff Young||Feb 2, 2012 5:48 am|
|Felix Meschberger||Feb 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|
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  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 ) - 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?
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.