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] > >
