sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Georg Henzler <>
Subject Re: [DISCUSS] Resource Mapping SPI
Date Tue, 31 Mar 2020 21:50:10 GMT
Hi Konrad,

yes, ResourceURI at the moment would be both for internal and external 

Immutable vs. Mutable is to be discussed (both ways have their own 

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

Because it is meant to be a pipeline of OSGi services in a row of which 
could make the decision to switch from a plain path to a full URI IMHO 
we need
to pass an interface that covers both. This approach could mean (names 
more descriptive than a real suggestion for now):

interface ResourceUri extends ArbitraryLink {...}
interface ResourcePath extends ArbitraryLink {...} # 

The ResourceMapping interface would then look symmetric again:

ArbitraryLink resolve(ArbitraryLink, ...)
ArbitraryLink map(ArbitraryLink, ...)


On 2020-03-30 21:17, Konrad Windszus wrote:
> 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
> <>:

> I definitely prefer immutable classes with a dedicated builder but
> that is up for another discussion I guess,
> Konrad
>> 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]

View raw message