Re: The beast that is JcrResourceResolverFactoryImpl
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
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 fmesc...@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 vidar.ram...@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
2012/2/2 Vidar Ramdal vidar.ram...@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 fmesc...@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 vidar.ram...@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
What is a whiteboard? (Is it equivalent to a sandbox?) Thanks, Jeff. -Original Message- From: Felix Meschberger [mailto:fmesc...@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 vidar.ram...@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 fmesc...@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 vidar.ram...@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
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:fmesc...@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 vidar.ram...@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 fmesc...@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 vidar.ram...@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
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
Re: The beast that is JcrResourceResolverFactoryImpl
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 2012/2/1 Carsten Ziegeler cziege...@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 vidar.ram...@webstep.no Webstep AS - http://www.webstep.no Besøksadresse: Lilleakerveien 8, 0283 Oslo Postadresse: Postboks 272 Lilleaker, 0216 Oslo
