sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Georg Henzler <ghenz...@apache.org>
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 
links.

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

> 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 
any
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 
are
more descriptive than a real suggestion for now):

interface ResourceUri extends ArbitraryLink {...}
interface ResourcePath extends ArbitraryLink {...} # 
RequestPathInfo+query+fragment

The ResourceMapping interface would then look symmetric again:

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

-Georg

On 2020-03-30 21:17, Konrad Windszus wrote:
> Hi Georg,
> 
> Is the class
> https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/uri/ResourceURI.java
> <https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/uri/ResourceURI.java>
> 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
> https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java
> <https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java>:
> 

> 
> 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 <ghenzler@apache.org> 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. rr.map() 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 rr.map() 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
>> rr.map() 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 ResourceMapping.java [5] and ResourceURI.java [6]
>> 
>> -Georg
>> 
>> [1] "[hackathon] externalization / resource mapping / rewriter" 
>> https://www.mail-archive.com/dev@sling.apache.org/msg87736.html
>> [2] "Why get rid of the rewriter?" 
>> https://www.mail-archive.com/dev@sling.apache.org/msg87867.html
>> [3] https://www.mail-archive.com/dev@sling.apache.org/msg87855.html
>> 
>> [4] 
>> https://github.com/apache/sling-org-apache-sling-api/compare/feature/Resource_Mapping_SPI
>> [5] 
>> https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/mapping/spi/ResourceMapping.java
>> [6] 
>> https://github.com/apache/sling-org-apache-sling-api/blob/7dd23418280fcef234b42dbabf6e13e43ef2d4d0/src/main/java/org/apache/sling/api/resource/uri/ResourceURI.java
>> 
>> 
>> 
>> 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 resourceResolver.map() 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 resourceResolver.map() - 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 <konrad_w@gmx.de> 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: 
>>>> https://issues.apache.org/jira/browse/SLING-9005 
>>>> <https://issues.apache.org/jira/browse/SLING-9005>
>>>> Konrad
>>>>> On 5. Sep 2019, at 17:54, Jason E Bailey <jason.bailey@24601.org>

>>>>> wrote:
>>>>> Specifically with regard to the re-writer
>>>>> I'm working on a replacement for this which I'm currently calling 
>>>>> the transformer -> 
>>>>> https://github.com/apache/sling-whiteboard/tree/master/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 wcm.io 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] https://wcm.io/handler/url/

Mime
View raw message