I would also opt for the revert as my first choice. The problem with the feature flag is, that I (wearing the Adobe hat) would start in the fully-backwards compatible mode to avoid regressions. And then I would need to slowly start enabling this feature and consistently look for errors. While this is possible to do with the product code, I see challenges with the code of our customers. And a realistic assumption is that we (Adobe) can never change this flag by default.
Jörg Am Di., 23. Sept. 2025 um 11:29 Uhr schrieb Konrad Windszus <[email protected] >: > 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] > > > > > -- https://cqdump.joerghoh.de
