Hi, The changes done were trying to address a shortcoming of the Sling CRUD API. Any other idea how to address those? I don’t like the idea of just giving up…
Or are we at a state where only bug fixing is supposed to be done? Even if the consensus is to revert I would strongly recommend to fix the Sling POST servlet (as I said it may also break for resource decorators). Konrad > On 23. Sep 2025, at 12:23, Carsten Ziegeler <[email protected]> wrote: > > I am not a fan of feature flags for these cases as this is a global switch. > If we enable it, post servlet is broken, if we disable it some new code might > be broken. > > Fixing all code with wrong assumptions sounds close to impossible to me. If > the post servlet already suffers from it, I am certain that there is a lot of > other code out there having the same assumption. > > I would vote for reverting, the reason why we never changed it some years ago > is most likely that it was breaking things. > > > Regards > Carsten > > On 9/23/2025 11:28 AM, Konrad Windszus wrote: >> Hi, >> After exposing sling:resourceTypes via the JCR Resource Provider >> (https://issues.apache.org/jira/browse/SLING-12781) we hit issue >> https://issues.apache.org/jira/browse/SLING-12944. It seems that there is >> some code (at least Sling POST servlet) assuming that all resource >> properties are backed by JCR properties (if the underlying resource is >> provided by the JCR Resource provider). >> Even before due to use of Resource decorators this was not necessarily true, >> but seems no one ever noticed the bug. >> Going forward there is the following options: >> 1) Revert changes from SLING-12781. >> 2) Fix code with wrong assumptions regarding properties exposed from JCR >> Resource Provider >> Also Jörg proposed that even when doing 2) at least the JCR resource >> provider changes regarding exposing the sling:resourceType as property >> should be gated by a feature flag. >> I would like to hear your opinions, >> Thanks in advance, >> Konrad >> On 2025/05/10 15:28:32 Carsten Ziegeler wrote: >>> I think in reality, this contract is obeyed by most resource providers: >>> https://github.com/apache/sling-org-apache-sling-api/blob/13ac9b09bb7bdc7e4baa2c62fd622421628a61f3/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L179 >>> >>> I also remember that we discussed some years ago that the value map must >>> return the resource type (using that property name) and also resource >>> super type (if set). >>> >>> I agree, that the current javadocs is very vague. I opt for making the >>> language strict (== required) and then check which resource providers we >>> need to fix to support this. >>> >>> We can do the same with the resource super type. >>> >>> Regards >>> Carsten >>> >>> On 09.05.2025 20:48, Konrad Windszus wrote: >>>> Hi, >>>> The resource resolver provides the following method for creating a new >>>> resource: >>>> >>>> "Resource create(@NotNull Resource parent, @NotNull String name, >>>> Map<String, Object> properties) throws PersistenceException" [1] >>>> >>>> However there is neither a parameter for providing the mandatory resource >>>> type nor for the (optional) resource super type or ResourceMetadata [2]. >>>> The resource type is not necessarily exposed via the underlying ValueMap() >>>> (just for the JCR resource provider this is the case as it stores the >>>> resource type in the node property with name “sling:resourceType”). Also >>>> those are immutable properties of a resource (i.e. there is no API to >>>> change those on existing resources). >>>> >>>> Compare also with the signature for creating a synthetic resource (which >>>> lacks support of resource super types, but supports at least resource type >>>> and resource metadata) [3]. >>>> >>>> So how is one supposed to create a resource with a dedicated resource type >>>> and super type in a provider-agnostic way? >>>> >>>> Thanks for your input, >>>> Konrad >>>> >>>> [1] - >>>> https://github.com/apache/sling-org-apache-sling-api/blob/13ac9b09bb7bdc7e4baa2c62fd622421628a61f3/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L787 >>>> [2] - >>>> https://sling.apache.org/documentation/the-sling-engine/resources.html#resource-properties >>>> [3] - >>>> https://github.com/apache/sling-org-apache-sling-api/blob/13ac9b09bb7bdc7e4baa2c62fd622421628a61f3/src/main/java/org/apache/sling/api/resource/SyntheticResource.java#L65 >>>> >>>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe >>> [email protected] >>> >>> > > -- > Carsten Ziegeler > Adobe > [email protected] > >
