You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Vidar Ramdal <vi...@webstep.no> on 2012/02/01 10:37:39 UTC
The beast that is JcrResourceResolverFactoryImpl
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 <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 02.02.2012 um 14:49 schrieb Jeff Young:
> What is a whiteboard? (Is it equivalent to a sandbox?)
Yes, we have a whiteboard/sandbox area in our svn at http://svn.apache.org/repos/asf/sling/whiteboard with the intent to prototype larger stuff before pushing it into trunk.
Regards
Felix
>
> Thanks,
> Jeff.
>
>
> -----Original Message-----
> From: Felix Meschberger [mailto:fmeschbe@adobe.com]
> Sent: 02 February 2012 13:42
> To: dev@sling.apache.org
> Subject: Re: The beast that is JcrResourceResolverFactoryImpl
>
> Hi,
>
> Am 02.02.2012 um 14:26 schrieb Vidar Ramdal:
>
>> 2012/2/2 Vidar Ramdal <vi...@webstep.no>:
>>>>>>> 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.
>>>
>>>> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>>>>> Great!
>>>>>
>>>>>> If we could find any references to Felix' prototype, I could start from there.
>>>>>
>>>>> Yes :) Or we can start from scratch - I think as a first step we could
>>>>> copy the jcr resource bundle to the whiteboard and start from there.
>>>
>>> 2012/2/2 Felix Meschberger <fm...@adobe.com>:
>>>> Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)...
>>>>
>>>> The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge)
>>>>
>>>> The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle.
>>>
>>> Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)
>
> That's exactly what I had in mind, yes.
>
>>>
>>>>
>>>> And yes, this would definitely be something I would be interested in.
>>>>
>>>> Could this work be started in a whiteboard location ?
>>>
>>> I created https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
>>> for this - will start by copying in the current jcr/resource bundle.
>
> Great !
>
>>>
>>> Unfortunately I don't get to do any Sling work in my current job, so
>>> don't expect any rapid progress on my part. Anyone interested, please
>>> join :)
>
>> Created https://issues.apache.org/jira/browse/SLING-2396 to track this.
>
> Thanks and Regards
> Felix
>
>>
>> --
>> Vidar S. Ramdal <vi...@webstep.no>
>> Webstep AS - http://www.webstep.no
>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
>
RE: The beast that is JcrResourceResolverFactoryImpl
Posted by Jeff Young <je...@adobe.com>.
What is a whiteboard? (Is it equivalent to a sandbox?)
Thanks,
Jeff.
-----Original Message-----
From: Felix Meschberger [mailto:fmeschbe@adobe.com]
Sent: 02 February 2012 13:42
To: dev@sling.apache.org
Subject: Re: The beast that is JcrResourceResolverFactoryImpl
Hi,
Am 02.02.2012 um 14:26 schrieb Vidar Ramdal:
> 2012/2/2 Vidar Ramdal <vi...@webstep.no>:
>>>>>> 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.
>>
>>> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>>>> Great!
>>>>
>>>>> If we could find any references to Felix' prototype, I could start from there.
>>>>
>>>> Yes :) Or we can start from scratch - I think as a first step we could
>>>> copy the jcr resource bundle to the whiteboard and start from there.
>>
>> 2012/2/2 Felix Meschberger <fm...@adobe.com>:
>>> Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)...
>>>
>>> The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge)
>>>
>>> The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle.
>>
>> Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)
That's exactly what I had in mind, yes.
>>
>>>
>>> And yes, this would definitely be something I would be interested in.
>>>
>>> Could this work be started in a whiteboard location ?
>>
>> I created https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
>> for this - will start by copying in the current jcr/resource bundle.
Great !
>>
>> Unfortunately I don't get to do any Sling work in my current job, so
>> don't expect any rapid progress on my part. Anyone interested, please
>> join :)
> Created https://issues.apache.org/jira/browse/SLING-2396 to track this.
Thanks and Regards
Felix
>
> --
> Vidar S. Ramdal <vi...@webstep.no>
> Webstep AS - http://www.webstep.no
> Besøksadresse: Lilleakerveien 8, 0283 Oslo
> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 02.02.2012 um 14:26 schrieb Vidar Ramdal:
> 2012/2/2 Vidar Ramdal <vi...@webstep.no>:
>>>>>> 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.
>>
>>> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>>>> Great!
>>>>
>>>>> If we could find any references to Felix' prototype, I could start from there.
>>>>
>>>> Yes :) Or we can start from scratch - I think as a first step we could
>>>> copy the jcr resource bundle to the whiteboard and start from there.
>>
>> 2012/2/2 Felix Meschberger <fm...@adobe.com>:
>>> Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)...
>>>
>>> The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge)
>>>
>>> The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle.
>>
>> Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)
That's exactly what I had in mind, yes.
>>
>>>
>>> And yes, this would definitely be something I would be interested in.
>>>
>>> Could this work be started in a whiteboard location ?
>>
>> I created https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
>> for this - will start by copying in the current jcr/resource bundle.
Great !
>>
>> Unfortunately I don't get to do any Sling work in my current job, so
>> don't expect any rapid progress on my part. Anyone interested, please
>> join :)
> Created https://issues.apache.org/jira/browse/SLING-2396 to track this.
Thanks and Regards
Felix
>
> --
> Vidar S. Ramdal <vi...@webstep.no>
> Webstep AS - http://www.webstep.no
> Besøksadresse: Lilleakerveien 8, 0283 Oslo
> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Vidar Ramdal <vi...@webstep.no>.
2012/2/2 Vidar Ramdal <vi...@webstep.no>:
>>>>> 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.
>
>> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>>> Great!
>>>
>>>> If we could find any references to Felix' prototype, I could start from there.
>>>
>>> Yes :) Or we can start from scratch - I think as a first step we could
>>> copy the jcr resource bundle to the whiteboard and start from there.
>
> 2012/2/2 Felix Meschberger <fm...@adobe.com>:
>> Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)...
>>
>> The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge)
>>
>> The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle.
>
> Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)
>
>>
>> And yes, this would definitely be something I would be interested in.
>>
>> Could this work be started in a whiteboard location ?
>
> I created https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
> for this - will start by copying in the current jcr/resource bundle.
>
> Unfortunately I don't get to do any Sling work in my current job, so
> don't expect any rapid progress on my part. Anyone interested, please
> join :)
Created https://issues.apache.org/jira/browse/SLING-2396 to track this.
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Vidar Ramdal <vi...@webstep.no>.
>>>> 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.
> Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>> Great!
>>
>>> If we could find any references to Felix' prototype, I could start from there.
>>
>> Yes :) Or we can start from scratch - I think as a first step we could
>> copy the jcr resource bundle to the whiteboard and start from there.
2012/2/2 Felix Meschberger <fm...@adobe.com>:
> Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)...
>
> The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge)
>
> The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle.
Sounds good. Maybe we also get to solve SLING-2076 [1] as a side-effect :)
>
> And yes, this would definitely be something I would be interested in.
>
> Could this work be started in a whiteboard location ?
I created https://svn.apache.org/repos/asf/sling/whiteboard/resourceresolverfactory
for this - will start by copying in the current jcr/resource bundle.
Unfortunately I don't get to do any Sling work in my current job, so
don't expect any rapid progress on my part. Anyone interested, please
join :)
[1] https://issues.apache.org/jira/browse/SLING-2076
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Sorry to chime in late,
Am 02.02.2012 um 09:02 schrieb Carsten Ziegeler:
>>> 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.
> Great!
>
>> If we could find
>> any references to Felix' prototype, I could start from there.
>
> Yes :) Or we can start from scratch - I think as a first step we could
> copy the jcr resource bundle to the whiteboard and start from there.
Unfortunately I don't have anything code-wise. I once started to separate the ResourceResolverFactory and ResourceResolver part from the JCR part but I didn't come very far (and I fear I lost my work)...
The basic idea, really is to split the JCR Resource bundle in a ResourceResolverFactory bundle and a JCR Resource Provider bundle (also providing the JCR Event to OSGi Event bridge)
The Domain Mapping functionality would be part of the ResourceResolverFactory bundle but would probably have a new exposed service API to plug into it. Such that for example Vanity URL functionality could in fact be factored out into another bundle.
And yes, this would definitely be something I would be interested in.
Could this work be started in a whiteboard location ?
Regards
Felix
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Carsten Ziegeler <cz...@apache.org>.
2012/2/1 Vidar Ramdal <vi...@webstep.no>:
>> 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)?
yes, exactly.
>
>> 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.
Great!
> If we could find
> any references to Felix' prototype, I could start from there.
Yes :) Or we can start from scratch - I think as a first step we could
copy the jcr resource bundle to the whiteboard and start from there.
Regards
Carsten
>
> --
> Vidar S. Ramdal <vi...@webstep.no>
> Webstep AS - http://www.webstep.no
> Besøksadresse: Lilleakerveien 8, 0283 Oslo
> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
--
Carsten Ziegeler
cziegeler@apache.org
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Vidar Ramdal <vi...@webstep.no>.
> 2012/2/1 Vidar Ramdal <vi...@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 <cz...@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.
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: The beast that is JcrResourceResolverFactoryImpl
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <vi...@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 <vi...@webstep.no>
> Webstep AS - http://www.webstep.no
> Besøksadresse: Lilleakerveien 8, 0283 Oslo
> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
--
Carsten Ziegeler
cziegeler@apache.org