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]
