sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konrad Windszus <>
Subject Re: [DISCUSS] Resource Mapping SPI
Date Mon, 30 Mar 2020 19:17:21 GMT
Hi Georg,

Is the class
supposed to be used for both internal as well as for external links?
I would rather come up with two separate classes (they don't have much in common).

What about a generic SlingUri class with the two specializations ResourceUri and AbsoluteUri
(or ExternalUri)?

That you would lead the following signatures in

ResourceUri resolve(ResourceURI, ...) (not useful for absolute/external URIs)
SlingUri map(SlingUri, ...) (can be useful even to map an external URI)

I definitely prefer immutable classes with a dedicated builder but that is up for another
discussion I guess,


> On 30. Mar 2020, at 02:13, Georg Henzler <> wrote:
> Hi all,
> so to eventually follow up on what has been discussed at last year's
> adaptTo Hackathon and in the mailing list afterwards [1]/[2] - I now
> found the time to draft the proposal for a Resource Mapping SPI.
> Two important points before we start:
> * This is not meant to replace the Rewriting Pipelines as they exist
>  today - it just would allow some Sling setups (maybe > 70%?) to move
>  to a simpler solution avoiding the overhead of the rewriter pipeline
>  while obviously losing its flexibility, but for many that will
>  be ok (I fully agree with Bertrand [3] here)
> * Let's focus the discussion first on if we would like to go into this
>  direction instead of details (like mutable vs. immutable or naming,
>  we can have detailed discussions around it once we decide to move on)
> But now to the actual proposal to introduce two new interfaces to the
> Sling API:
> ResourceURI:
> On Sling API level we treat links as strings (e.g. returns
> a String). Using Strings for links has produced many bugs in the past,
> I think having an abstraction for a URI/link that is tailored for
> Sling would help a lot (obviously plain JDK URI can be used, but
> there is no support for selectors, suffix etc.).
> Besides being generally a good idea IMHO, ResourceURI shall be used
> for the other interface:
> ResourceMapper:
> Allows to hook into the rr.resolve() and by implementing
> exactly those two methods that work on instances of ResourceURI. The
> idea is that n OSGi service instances of ResourceMapper build a
> pipeline of mappers that rr would run through when rr.resolve() or
> is called (in the opposite direction for map). The request
> is passed in as context to both methods but may be null as it is
> today, implementations of ResourceMapper need to be able to handle
> null.
> The following mechanisms exist today for resource mapping in ootb
> Sling:
> * Config "resource.resolver.mapping" in JcrResourceResolverFactoryImpl
> * Mappings via /etc/map
> * Vanity Paths
> * sling:alias
> Those could be broken up into four implementations of ResourceMapper
> that are configured by default.
> About backwards-compatibility/breaking existing implementations: So
> this is a BIG CHANGE. However to keep it safe I would start with
> exactly one ResourceMapper active that is backed by today's
> implementation. The next step is to break it in separate resource
> mappers (as mentioned above) and just put them in a row.
> The Resource Mapping SPI would bring the following benefits:
> * Being able to hook into the resource mapping via SPI allows
>  for flexibility that is otherwise only possible Rewriting
>  Pipelines - while link rewriting/checking is the only
>  reason most projects use Rewriting Pipelines (with all its
>  performance overhead)
> * Extending the mapping process via a well-defined API that
>  allows to write Touring-complete code is better than working
>  with Strings in the Transformer (also for many cases it can
>  be cleaner and better 'unit-testable' than /etc/maps)
> * HTL there can be an option to automatically map all
>  attributes of context uri (better performance, better for
>  debugging if map() is called synchronously)
> * Introducing the interface ResourceURI (with a backing helper
>  class for everybody to use) is useful in general
> See branch [4] for some first code of the proposal, in
> particular [5] and [6]
> -Georg
> [1] "[hackathon] externalization / resource mapping / rewriter"
> [2] "Why get rid of the rewriter?"
> [3]
> [4]
> [5]
> [6]
> On 2020-01-17 10:45, Georg Henzler wrote:
>> Hi Konrad,
>> I think SLING-9005 is a good idea, but that is independent.
>> My idea idea was to leave unchanged (as there
>> is a lot of code using it out there, also it makes conceptually sense
>> as is). Rather I‘d like to provide an SPI that allows to customize the
>> way of the behavior of - I‘m thinking of a
>> ranked list of ResourceMapper services (default one being today’s
>> behavior). Robert also has done some work into this direction already,
>> I‘d like to extend on that.
>> I‘m currently on vacation but I have it on my list for when I‘m back.
>> -Georg
>>> On 16. Jan 2020, at 15:01, Konrad Windszus <> wrote:
>>> I would like to revive this.
>>> @Georg: IIRC you wanted to come up with a proposal for a externalizer API. Are
you working on this?
>>> Can we start by creating a JIRA ticket?
>>> There has been a related ticket opened today:
>>> Konrad
>>>> On 5. Sep 2019, at 17:54, Jason E Bailey <> wrote:
>>>> Specifically with regard to the re-writer
>>>> I'm working on a replacement for this which I'm currently calling the transformer
>>>> 1. It uses an HTML tokenizer that was added to the HTML utilities to generate
a stream of  elements that can be modified and recombined. It's much faster then tagsoup or
jsoup since it's not trying to build a valid document. This also means that it supports anything
that you write out in html. HTML4,5+
>>>> 2. It uses services with an ordering priority and does pattern matching so
that you can fine tune when the transformer is applied
>>>> 3. The specific use case I was working on is creating a CSP header with a
nonce or hash attribute to lock down the javascript that's on the page.
>>>> It's currently working but it's not finished.
>>>> Are there other problems with the rewriter that I haven't addressed?
>>>> --
>>>> Jason
>>>>> On Thu, Sep 5, 2019, at 10:34 AM, Stefan Seifert wrote:
>>>>> - resource mapping
>>>>> - add a new SPI to define the mapping
>>>>> - add a default impl that reads the mapping from /etc/map as it is
>>>>> done today
>>>>> - possible to override with service ranking
>>>>> - but: there is already the ResourceMapper interface
>>>>>  - introduced 1-2 years ago, use case was to get all existing
>>>>> mappings
>>>>>  - with this it's currently possible to replace mapping completely
>>>>> with new logic
>>>>> - maybe add a support to "contribute" additional mappings via a
>>>>> service interface additional to this
>>>>> - generic externalizer API
>>>>> - naming not fixed yet, should not named "link" as this is too
>>>>> specific. probably "URL".
>>>>> - needs a java API for using, and an SPI for hooking in special rules
>>>>> - then add mappings for views in HTL*, JSP, model exporter/JSON
>>>>>  * probably starting with a sling-only HTL extension for try-out,
>>>>> add it later to the spec when design is validated
>>>>> - might be inspired by the basic features for URL handler [1]
>>>>> - rewriter pipeline
>>>>> - should be deprecated and no longer be used - especially not for
>>>>> link externalization via postprocessing
>>>>> - it may still be in use out there for more exotic use cases like PDF
>>>>> generation
>>>>> - should probably removed from sling starter
>>>>> stefan
>>>>> [1]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message