Re: OSGi Compendium
Dominik Süß wrote: Wouldn't it be more straight forward to exclude the Compendium Libraries from the Declarative Services as well and have it as seperate bundle in general? I know this thoughts might lead to a big amount of small bundles and some might not like this, but in this case I think it really would make sense. This actually would require to split up the compendium into the various parts and have an api bundle for each part. Updating the DS then would require to update the api and the impl bundle. Hmm, not sure what the better option is. At least, it seems that pre bundling the compendium libs is wrong. So +1 to remove them from launchpad/base. I like the way how the Apache Felix DS implementation does it. You get one bundle containing everything you need. So updating to a new spec version is pretty simply as the bundle is self contained. How do other implementations do this? Carsten Regards, Dominik On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi all, Currently the Sling launcher (in the launchpad/base module) contains the Felix framework, the OSGi Core libraries as well as the OSGi Compendium libraries. While working on the implementation of the new Declarative Services 1.1 features planned for addition in the OSGi Compendium Specification 4.2 I ran into a problem with this setup. Consider a bundle X importing the Declarative Services packages *before* the new implementation is installed. Both the system bundle (as per the launchpad/base module) and the Declarative Services implementation export version 1.0 of the org.osgi.service.component package. This results in all bundles wiring to the system bundle. Everything is fine. Now update the Declarative Services bundle which now exports version 1.1 of the org.osgi.service.component package. The Declarative Services bundle binds to its own export using the latest version available. Bundle X is still wired to the system bundle because there is no rewiring taking place. The consequence is, that the new Declarative Services bundle cannot call any of the activate or deactivate methods of the components in Bundle X because the ComponentContext argument is not compatible. As a fix, I suggest we modify the launchpad/base bundle to *not* provide the Compendium packages any more. Instead we will expect that either the Compendium implementation bundles export the packages (as for example the Apache Felix Declarative Services bundle does) or that the compendium packages are installed as a bundle. WDYT ? Regards Felix -- Carsten Ziegeler cziege...@apache.org
Revisiting the resource super type handling
Hi, while changing the script resolution in the last days a little bit to make it cacheable, I stumbled across the handling of the resource super type. The jcr resource implementation checks if the node has the sling:resourceSuperType property and returns this value if existent. If not, it tries to find a resource under the search paths (usually libs and apps) with the resource type converted to a path. So if a resource has the type a/b, the resources /apps/a/b and /libs/a/b are tested if they exist and contain a resource super type property. Other resource implementations like the bundle resource always returns null. The fs resource implemenations returns a special resource type for the resource super type. I think this behaviour is a little bit inconsistent. I would change it that if a resource does not know it's super type, it should return null. So basically this effects the implementation of the jcr resource. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. Otherwise each resource implemenation should apply the algorithm to be consistent. But I would prefer the first solution. While the change is incompatible, I think this doesn't have any real effect. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
Snapshot versions in repository.apache.org
Hi, We are seeing build failires in our project when we depend on SNAPSHOTs from repositroy.apache.org The error is [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.sling ArtifactId: sling Version: 6-incubator-20090609.084848-3 Reason: Unable to locate resource in repository org.apache.sling:sling:pom:6-incubator-20090609.084848-3 because http://repository.apache.org/snapshots//org/apache/sling/sling/6-incubator-SNAPSHOT/sling-6-incubator-20090609.084848-3.pom does not exist http://repository.apache.org/snapshots//org/apache/sling/sling/6-incubator-SNAPSHOT/sling-6-incubator.pom does. If I edit my local ~/.m2/repository/org/apache/sling/6-incubator-SNAPSHOT/maven-metadata- apache-snapshots.xml and remove the the snapshot tag .. eg versioning !-- snapshot timestamp20090609.084848/timestamp buildNumber3/buildNumber /snapshot -- lastUpdated20090617104717/lastUpdated /versioning The build works again. Any ideas ? Ian
git://git.apache.org/sling.git
Now that the svn repo has moved, has the git mirror been updated ? I am not getting any updates through. Ian
[Fwd: git://git.apache.org/sling.git]
Hi all, We have move the Sling source code to its new top level location http://svn.apache.org/repos/asf/sling. It looks like the GIT mirror setup is still referring to the old incubator location at http://svn.apache.org/repos/asf/incubator/sling. Can someone please take care of this ? Thanks alot. Regards Felix Original-Nachricht Betreff: git://git.apache.org/sling.git Datum: Fri, 26 Jun 2009 09:58:07 +0100 Von: Ian Boston i...@tfd.co.uk Antwort an: sling-dev@incubator.apache.org An: sling-dev@incubator.apache.org Now that the svn repo has moved, has the git mirror been updated ? I am not getting any updates through. Ian
Re: OSGi Compendium
Carsten Ziegeler schrieb: Dominik Süß wrote: Wouldn't it be more straight forward to exclude the Compendium Libraries from the Declarative Services as well and have it as seperate bundle in general? I know this thoughts might lead to a big amount of small bundles and some might not like this, but in this case I think it really would make sense. This actually would require to split up the compendium into the various parts and have an api bundle for each part. Updating the DS then would require to update the api and the impl bundle. Hmm, not sure what the better option is. At least, it seems that pre bundling the compendium libs is wrong. So +1 to remove them from launchpad/base. I like the way how the Apache Felix DS implementation does it. You get one bundle containing everything you need. So updating to a new spec version is pretty simply as the bundle is self contained. Actually the Apache Felix DS implementation also exports the Configuration Admin packages. This will probably be removed for the next release. How do other implementations do this? AFAICT the Eclipse/Equinox project is using the approach of not including the API in the implementation bundles but to have you install the compendium library bundle. There are basically two approaches to the question of where to locate API with respect to the implementations: One is to include the implemented API with the implementation. The other is to strictly separate API from implementation. My stance is somewhere in-between. Generally I prefer separating the API from the implementation, unless ... For example, in Sling we have the Sling API bundle. This is IMHO a coherent API which is implemented by multiple bundles, e.g. the engine and the jcr/resource bundles. This API is separate. On the other hand we have the exported API of the jcr/resource bundle. While we could separate it out into a separate bundle, the resulting bundle would be so small, that it probably makes no sense. In addition, chances of another implementation of that API are close to zero. For the compendium API, the case is that the Compendium library is a collection of more or less unrelated packages (there is close to no interpackage references on the API level). So having one Compendium bundle tends to lead to issues if we upgrade the implementations independetly of the versioning of the different packages. As a result, in Apache Felix we export the respective API from the implementation bundles. This also makes it easy to upgrade the API. Regards Felix Carsten Regards, Dominik On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger fmesc...@gmail.comwrote: Hi all, Currently the Sling launcher (in the launchpad/base module) contains the Felix framework, the OSGi Core libraries as well as the OSGi Compendium libraries. While working on the implementation of the new Declarative Services 1.1 features planned for addition in the OSGi Compendium Specification 4.2 I ran into a problem with this setup. Consider a bundle X importing the Declarative Services packages *before* the new implementation is installed. Both the system bundle (as per the launchpad/base module) and the Declarative Services implementation export version 1.0 of the org.osgi.service.component package. This results in all bundles wiring to the system bundle. Everything is fine. Now update the Declarative Services bundle which now exports version 1.1 of the org.osgi.service.component package. The Declarative Services bundle binds to its own export using the latest version available. Bundle X is still wired to the system bundle because there is no rewiring taking place. The consequence is, that the new Declarative Services bundle cannot call any of the activate or deactivate methods of the components in Bundle X because the ComponentContext argument is not compatible. As a fix, I suggest we modify the launchpad/base bundle to *not* provide the Compendium packages any more. Instead we will expect that either the Compendium implementation bundles export the packages (as for example the Apache Felix Declarative Services bundle does) or that the compendium packages are installed as a bundle. WDYT ? Regards Felix
[jira] Updated: (SLING-1023) Allow NonExistant Resources to have a Resource Type
[ https://issues.apache.org/jira/browse/SLING-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston updated SLING-1023: -- Attachment: SLING-1023.patch Here is a patch against r788637 I would also be happy to contribute something that uses it eg http://github.com/ieb/open-experiments/blob/7df1869137eba26e4b2af1d5da966af4ec59c0d6/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/AbstractPathResourceTypeProvider.java http://github.com/ieb/open-experiments/blob/7df1869137eba26e4b2af1d5da966af4ec59c0d6/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/AbstractVirtualPathServlet.java http://github.com/ieb/open-experiments/blob/7df1869137eba26e4b2af1d5da966af4ec59c0d6/slingtests/osgikernel/bundles/resource/src/main/java/org/sakaiproject/kernel/resource/VirtualResource.java Allow NonExistant Resources to have a Resource Type --- Key: SLING-1023 URL: https://issues.apache.org/jira/browse/SLING-1023 Project: Sling Issue Type: Improvement Affects Versions: JCR Resource 2.0.4 Reporter: Ian Boston Attachments: SLING-1023.patch We have been using a patch to the jcr.resolver bundle that allows us to map non existent resources to a resource type so that they can be handled by a servlet registered to that resource type. Our use case is to allow a node to act as a marker and container for the virtual store where the URL path does not equal the JCR storage path. eg the URL /_user/messages/ieb/101 maps to /_user/messages/ed/fe/45/3e/ieb/23/ef/e4/d0/101 where only the node /_user/messages is marked with a resource type. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi Compendium
Felix Meschberger schrieb: Carsten Ziegeler schrieb: Dominik Süß wrote: Wouldn't it be more straight forward to exclude the Compendium Libraries from the Declarative Services as well and have it as seperate bundle in general? I know this thoughts might lead to a big amount of small bundles and some might not like this, but in this case I think it really would make sense. This actually would require to split up the compendium into the various parts and have an api bundle for each part. Updating the DS then would require to update the api and the impl bundle. Hmm, not sure what the better option is. At least, it seems that pre bundling the compendium libs is wrong. So +1 to remove them from launchpad/base. I like the way how the Apache Felix DS implementation does it. You get one bundle containing everything you need. So updating to a new spec version is pretty simply as the bundle is self contained. Actually the Apache Felix DS implementation also exports the Configuration Admin packages. This will probably be removed for the next release. How do other implementations do this? AFAICT the Eclipse/Equinox project is using the approach of not including the API in the implementation bundles but to have you install the compendium library bundle. There are basically two approaches to the question of where to locate API with respect to the implementations: One is to include the implemented API with the implementation. The other is to strictly separate API from implementation. My stance is somewhere in-between. Generally I prefer separating the API from the implementation, unless ... For example, in Sling we have the Sling API bundle. This is IMHO a coherent API which is implemented by multiple bundles, e.g. the engine and the jcr/resource bundles. This API is separate. On the other hand we have the exported API of the jcr/resource bundle. While we could separate it out into a separate bundle, the resulting bundle would be so small, that it probably makes no sense. In addition, chances of another implementation of that API are close to zero. For the compendium API, the case is that the Compendium library is a collection of more or less unrelated packages (there is close to no interpackage references on the API level). So having one Compendium bundle tends to lead to issues if we upgrade the implementations independetly of the versioning of the different packages. Yepp, exactly. That's why we either have to split up the compendium into several api bundles (one for DS, one for config admin etc.) or the implementations should bundle it. It is a little bit strange that while OSGi is about modularity the compendium is a single library :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [Fwd: git://git.apache.org/sling.git]
Hi, Ok, will do that. Thanks. Regards Felix Tony Stevenson schrieb: Felix, Send this to infrastructure-dev -- Where Jukka and Gregorz will likely see it and fix it up for you. On 26 Jun 2009, at 10:33, Felix Meschberger wrote: Hi all, We have move the Sling source code to its new top level location http://svn.apache.org/repos/asf/sling. It looks like the GIT mirror setup is still referring to the old incubator location at http://svn.apache.org/repos/asf/incubator/sling. Can someone please take care of this ? Thanks alot. Regards Felix Original-Nachricht Betreff: git://git.apache.org/sling.git Datum: Fri, 26 Jun 2009 09:58:07 +0100 Von: Ian Boston i...@tfd.co.uk Antwort an: sling-dev@incubator.apache.org An: sling-dev@incubator.apache.org Now that the svn repo has moved, has the git mirror been updated ? I am not getting any updates through. Ian Cheers, Tony Tony Stevenson t...@pc-tony.com - pct...@apache.org pct...@freenode.net - t...@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66 ECAF DC55 C608 5E82 0B5E 3359 C9C7 924E 5104 7D66
[jira] Closed: (SLING-987) Jobs/Events are purged in an uncontrolled way
[ https://issues.apache.org/jira/browse/SLING-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-987. -- Resolution: Fixed Jobs/Events are purged in an uncontrolled way - Key: SLING-987 URL: https://issues.apache.org/jira/browse/SLING-987 Project: Sling Issue Type: Bug Components: Event Affects Versions: Extensions Event 2.0.4 Reporter: Philipp Koch Assignee: Carsten Ziegeler Priority: Blocker Fix For: Extensions Event 2.0.6 We already had this problem for pretty big event/job queues once (a month ago or so. could not find a jira issue) that the job in the queue got purged because the job acknowledge timed out for that job (by default the job/event is purged after 3 timeouts). the above mentioned fix fixed the issue quite well. it appeared now again when running such big queues on very fast boxes: 9.05.2009 13:00:07.904 *INFO* [pool-4-thread-1] org.apache.sling.event.impl.JobEventHandler No acknowledge received for job org.osgi.service.event.Event [topic=com/day/cq/workflow/job] stored at /var/eventing/jobs/com.day.cq.workflow.job/Job5a50f993-8f36-4eae-81d5-3124ca455bf5. Requeueing job. the funny thing is now that the timeout does not happen after hours but already after 10 mins. there are no (debug) log entries that would point to some event handler problems... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Revisiting the resource super type handling
On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegelercziege...@apache.org wrote: Hi, while changing the script resolution in the last days a little bit to make it cacheable, I stumbled across the handling of the resource super type. The jcr resource implementation checks if the node has the sling:resourceSuperType property and returns this value if existent. If not, it tries to find a resource under the search paths (usually libs and apps) with the resource type converted to a path. So if a resource has the type a/b, the resources /apps/a/b and /libs/a/b are tested if they exist and contain a resource super type property. Other resource implementations like the bundle resource always returns null. The fs resource implemenations returns a special resource type for the resource super type. I think this behaviour is a little bit inconsistent. I would change it that if a resource does not know it's super type, it should return null. So basically this effects the implementation of the jcr resource. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. Otherwise each resource implemenation should apply the algorithm to be consistent. But I would prefer the first solution. While the change is incompatible, I think this doesn't have any real effect. i agree that the resource should not know about search paths. imo, the resource resolver should be used for 'resolving' the resource super type. regards, toby
[jira] Commented: (SLING-1023) Allow NonExistant Resources to have a Resource Type
[ https://issues.apache.org/jira/browse/SLING-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724495#action_12724495 ] Ian Boston commented on SLING-1023: --- There is a potential problem with this patch in the way that the RequestPathInfo is generated. At the moment it doesn't correctly cause selectors to parse properly. I will update. Allow NonExistant Resources to have a Resource Type --- Key: SLING-1023 URL: https://issues.apache.org/jira/browse/SLING-1023 Project: Sling Issue Type: Improvement Affects Versions: JCR Resource 2.0.4 Reporter: Ian Boston Attachments: SLING-1023.patch We have been using a patch to the jcr.resolver bundle that allows us to map non existent resources to a resource type so that they can be handled by a servlet registered to that resource type. Our use case is to allow a node to act as a marker and container for the virtual store where the URL path does not equal the JCR storage path. eg the URL /_user/messages/ieb/101 maps to /_user/messages/ed/fe/45/3e/ieb/23/ef/e4/d0/101 where only the node /_user/messages is marked with a resource type. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Revisiting the resource super type handling
Hi, Tobias Bocanegra schrieb: On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegelercziege...@apache.org wrote: Hi, while changing the script resolution in the last days a little bit to make it cacheable, I stumbled across the handling of the resource super type. The jcr resource implementation checks if the node has the sling:resourceSuperType property and returns this value if existent. If not, it tries to find a resource under the search paths (usually libs and apps) with the resource type converted to a path. So if a resource has the type a/b, the resources /apps/a/b and /libs/a/b are tested if they exist and contain a resource super type property. Other resource implementations like the bundle resource always returns null. The fs resource implemenations returns a special resource type for the resource super type. I think this behaviour is a little bit inconsistent. I would change it that if a resource does not know it's super type, it should return null. So basically this effects the implementation of the jcr resource. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. Otherwise each resource implemenation should apply the algorithm to be consistent. But I would prefer the first solution. While the change is incompatible, I think this doesn't have any real effect. i agree that the resource should not know about search paths. imo, the resource resolver should be used for 'resolving' the resource super type. Actually, the ResourceResolver *is* used to resolve the super type from a resource type resource: // resource type rel path, e.g. nt/file String path = resourceTypeToPath(resourceType); // resolve resource type resource Resource rtResource = resourceResolver.getResource(path); The getResource method applies the current search path as described and required and requested. Regards Felix
Re: Revisiting the resource super type handling
Hi, Carsten Ziegeler schrieb: Hi, while changing the script resolution in the last days a little bit to make it cacheable, I stumbled across the handling of the resource super type. The jcr resource implementation checks if the node has the sling:resourceSuperType property and returns this value if existent. If not, it tries to find a resource under the search paths (usually libs and apps) with the resource type converted to a path. So if a resource has the type a/b, the resources /apps/a/b and /libs/a/b are tested if they exist and contain a resource super type property. Other resource implementations like the bundle resource always returns null. The fs resource implemenations returns a special resource type for the resource super type. I think this behaviour is a little bit inconsistent. I agree, that the behaviour of the Resource.getResourceType() implementation for the bundle resource and filesystem resource implementations is inconsistent. The filesystem provider returns sling/fs/resource as its super type. IMHO this is an interesting abstraction to apply common behaviour to filesystem provided resources. Therefore, I suggest we enhance the bundle resource provider to return sling/bundle/resource as the resource super type. I would change it that if a resource does not know it's super type, it should return null. So it is currently implemented and defined, IIUIC. So basically this effects the implementation of the jcr resource. So the JcrNodeResource returns the value of the sling:resourceSuperType property if set. If the property is not set, null is just returned. The JcrPropertyResource returns null immediately, since a property does not have a property. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. The servlet resolver should first do a Resource.getSuperType(). After that the resource type (or the resource super type) is used as the basis for the ResourceUtil.getResourceSuperType(ResourceResolver, String) method. Right ? Consequently: * ResourceUtil.getResourceSuperType(ResourceResolver, String) remains as is resolving the resource super type as the supertype of the resource type resource. * ResourceUtil.getResourceSuperType(Resource) is removed, since it brings no added value (it only has been added yesterday). * JcrResourceUtil.getResourceSuperType(ResourceResolver, String) is deprecated and is implemented calling the new ResourceUtil.getResourceSuperType(ResourceResolver, String) method. * JcrResourceUtil.getResourceSuperType(Resource) is deprecated and is implemented to call Resource.getSuperType() on the resource first and then calling ResourceUtil.getSuperType(ResourceResolver, resource.getResourceType()) as a fallback. Is that what you had in mind ? Regards Felix Otherwise each resource implemenation should apply the algorithm to be consistent. But I would prefer the first solution. While the change is incompatible, I think this doesn't have any real effect. WDYT?
Re: Script Context custom Bindings for engines
If you mean mapping jcr nodes to domain objects you might want to use OCM [1]. You have an example appying OCM at [2]. And if you want to hand-craft the adapters you may even want to implement an AdapterFactory.. Maybe even better than OCM because it wouldn´t be tied up with JCR. Juanjo.
RE: Script Context custom Bindings for engines
Hi Felix, hi Juanjo If you mean mapping jcr nodes to domain objects you might want to use OCM [1]. You have an example appying OCM at [2]. And if you want to hand-craft the adapters you may even want to implement an AdapterFactory.. Maybe even better than OCM because it wouldn´t be tied up with JCR. Juanjo. Is there any sample of an AdapterFactory, so that I can document this? best regards mike
[jira] Commented: (SLING-1023) Allow NonExistant Resources to have a Resource Type
[ https://issues.apache.org/jira/browse/SLING-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724616#action_12724616 ] Alexander Klimetschek commented on SLING-1023: -- (arg, I just sent my comment, but the server didn't answer, so it was completely lost) I would object against making the NonExistingResource implementation non-final, and allow to override the sling:nonexisting nodetype. That might be a serious backwards incompatability. A mechanism to handle non-existing paths differently should rather work after the resource type was defined. The reason is that parsing the resource path etc. is not easily possible, so it might be in the eyes of the actual handler what is path, what is selector and what is extension. We have a temporary, albeit maybe not perfect, solution for this issue by registering a special servlet for all non-existing requests (/apps/sling/nonexisting/GET.servlet, /apps/sling/nonexisting/POST.servlet, /apps/sling/nonexisting/PUT.servlet) and having it itself dispatch to other OptingServlets that can be registered as osgi services. The first one to say accept for a non-existing resource will be used. See also a related discussion on this: http://markmail.org/message/52m32zh36ewo4xl2 Allow NonExistant Resources to have a Resource Type --- Key: SLING-1023 URL: https://issues.apache.org/jira/browse/SLING-1023 Project: Sling Issue Type: Improvement Affects Versions: JCR Resource 2.0.4 Reporter: Ian Boston Attachments: SLING-1023.patch We have been using a patch to the jcr.resolver bundle that allows us to map non existent resources to a resource type so that they can be handled by a servlet registered to that resource type. Our use case is to allow a node to act as a marker and container for the virtual store where the URL path does not equal the JCR storage path. eg the URL /_user/messages/ieb/101 maps to /_user/messages/ed/fe/45/3e/ieb/23/ef/e4/d0/101 where only the node /_user/messages is marked with a resource type. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1023) Allow NonExistant Resources to have a Resource Type
[ https://issues.apache.org/jira/browse/SLING-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724719#action_12724719 ] Ian Boston commented on SLING-1023: --- What would make the patch acceptable ? SyntheticResource ? Setting the resource supertype (although I think this might have just gone) ? IMHO the nonexisting approach adds a second level of resource dispatching, which I really would prefer not to have, not least At the moment we are on a branch with this in, since (I am sorry to say this, and absolutely no offense intended because everything else *is* fantastic!) Sling/Jackrabbit doesn't scale 1000 syblings at one location in a URL space if its mapped directly to JCR paths. We have ~100K users, and they all need a number of predictable home storage spaces and a number of predictable message storage spaces, which I dont want to hard code or expose unfriendly urls. We can keep going on our branch, but I keep on seeing others with similar problems on lists, not just sling-dev, and having a branch like this makes me nervous. Allow NonExistant Resources to have a Resource Type --- Key: SLING-1023 URL: https://issues.apache.org/jira/browse/SLING-1023 Project: Sling Issue Type: Improvement Affects Versions: JCR Resource 2.0.4 Reporter: Ian Boston Attachments: SLING-1023.patch We have been using a patch to the jcr.resolver bundle that allows us to map non existent resources to a resource type so that they can be handled by a servlet registered to that resource type. Our use case is to allow a node to act as a marker and container for the virtual store where the URL path does not equal the JCR storage path. eg the URL /_user/messages/ieb/101 maps to /_user/messages/ed/fe/45/3e/ieb/23/ef/e4/d0/101 where only the node /_user/messages is marked with a resource type. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
