+1 Jeff.
> -----Original Message----- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: 29 March 2012 19:25 > To: dev@sling.apache.org > Subject: Re: [ResourceResolver] sling:alias support > > Hi, > > This is kind of strong evidence IMHO. Thanks for sharing. > > Regards > Felix > > Am 29.03.2012 um 11:44 schrieb Antonio Sanso: > > > Hi Jeff, > > > > in [0] you can find a kind of evidence for it. > > > > Regards > > > > Antonio > > > > [0] https://issues.apache.org/jira/browse/SLING-2311 > > > > On Feb 24, 2012, at 1:48 PM, Jeff Young wrote: > > > >> Felix, > >> > >> Have we done any profiling to confirm that sling:alias resolution > does actually contribute a meaningful percentage? > >> > >> Jeff. > >> > >> > >> -----Original Message----- > >> From: Felix Meschberger [mailto:fmesc...@adobe.com] > >> Sent: 24 February 2012 10:13 > >> To: dev@sling.apache.org > >> Subject: [ResourceResolver] sling:alias support > >> > >> Hi all, > >> > >> We have had support for sling:alias properties for a long time. This > allows to create URL aliases for example for i18n. Yet, it also creates > some overhead for resolution of non-existing URLs. > >> > >> Whenever an URL cannot directly be resolved it is split in segments > and the resource tree is walked down from the top resolving each > segment: If a child resource is not found, all children are inspected > for a sling:alias property. Only if none has been found, the iteration > terminates and resource resolution fails. > >> > >> This is potentially a costly operation and may not always be > required. > >> > >> I wonder, whether we should have a configuration option to be able > to switch off sling:alias support (Default would be enabled sling:alias > support for backwards compatibility). > >> > >> Regards > >> Felix > >
