IMHO your NonExistingResource or SynthetricResource should already have the correct absolute path. As Rob noted, RR.resolve() is about resolving URIs to Resources. Once you are navigating Resources (e.g. getParent()), no more resolve() calls should happen.
>From my point of view the problem is that the mapping (/ -> /content/) is not applied when the URI is resolved. I would expect that you get: nonExistingResource.getPath() -> "/content/existingParent/nonExistingResource" (IMO getting "/existingParent/nonExistingResource" here is a bug) nonExistingResource.getParent().getPath() -> "/content/existingParent" (exists) What would be involved in fixing the (IMO) correct resolution of the "nonExistingResource"? Regards Julian On Fri, Jun 10, 2016 at 5:12 PM, Konrad Windszus <konra...@gmx.de> wrote: > I am talking about > https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L254 > > <https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/scripting/sightly/engine/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/ResourceRuntimeExtension.java#L254> > here. > The best would be if the SyntheticResource would optionally get a list of > possible resolved resource locations. If we add another constructor taking an > additional List<String> with possible resolved repository paths we would be > able to consider that list in the getParent(). > That way we would not directly rely on ResourceResolver.resolve() within > getParent() but just try getParent() for the different possible repository > paths until we find a matching one, or if we don't find a matching one return > a NonExistingResource(), again being feeded with the same list of possible > resolved repository paths. > WDYT? > Konrad > > >> On 10 Jun 2016, at 10:13, Carsten Ziegeler <cziege...@apache.org> wrote: >> >> Konrad Windszus wrote >>> My use case is AEM: >>> I have an existing page containing some components (each one encapsulated >>> in dedicated child resources). >>> Now the underlying template in AEM is extended (i.e. new fixed components >>> have been added). For each of those a child resource is necessary, which >>> does not exist yet on older pages (being created at a point in time, where >>> the template did not have that component yet). >>> >>> In Sightly we include those new components via data-sly-use with an >>> explicit resourceType. Sightly will first try to get the child resource >>> with that path. If it does not exist yet it will create a SyntheticResource >>> with the given resource type. >>> For example to get the cloud service configuration we would need to get the >>> (existing) container AEM page for the SyntheticResource. This currently >>> fails, because of the issues mentioned. >>> >>> If this would work, the component would be rendered fine (even acting on a >>> SyntheticResource). >> >> Ok, so I guess this can be easily solved in Sightly as this sounds to me >> like a Sightly use case. >> >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >
