You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <kw...@apache.org> on 2025/09/23 09:28:59 UTC
Re: Creating new resources via ResourceResolver API with resource type in a provider-agnostic way
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
> cziegeler@apache.org
>
>
Re: Creating new resources via ResourceResolver API with resource type in a provider-agnostic way
Posted by Jörg Hoh <jh...@googlemail.com.INVALID>.
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 <kwin@apache.org
>:
> 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
> > cziegeler@apache.org
> >
> >
>
--
https://cqdump.joerghoh.de
Re: Creating new resources via ResourceResolver API with resource type in a provider-agnostic way
Posted by Carsten Ziegeler <cz...@apache.org>.
I don't think we are at a bug fixing only state. We are at a state where
for more than 15+ years code has been written using our APIs and
implementations. And making any tiny incompatible change might have a
huge effect, even if it looks like the right thing to do. So we have to
be careful.
This is a very good example, no one of us (including myself) thought it
will cause a problem, but it did already in our own code. And that is a
very good sign that code out of our hands will do similar. We have seen
this in the 15+ years so often.
But again, this doesn't mean we can only do bug fixing. But whatever new
functionality we add, it needs to be carefully woven in to not break
existing code - which is especially hard for these low level things we
are discussing here. Which then poses the question whether fixing such a
shortcoming is really worth the effort. I honestly don't know.
Regards
Carsten
On 9/23/2025 12:49 PM, Konrad Windszus wrote:
> 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 <cz...@apache.org> 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
>>>> cziegeler@apache.org
>>>>
>>>>
>>
>> --
>> Carsten Ziegeler
>> Adobe
>> cziegeler@apache.org
>>
>>
>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org
Re: Creating new resources via ResourceResolver API with resource type in a provider-agnostic way
Posted by Konrad Windszus <kw...@apache.org>.
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 <cz...@apache.org> 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
>>> cziegeler@apache.org
>>>
>>>
>
> --
> Carsten Ziegeler
> Adobe
> cziegeler@apache.org
>
>
Re: Creating new resources via ResourceResolver API with resource type in a provider-agnostic way
Posted by Carsten Ziegeler <cz...@apache.org>.
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
>> cziegeler@apache.org
>>
>>
--
Carsten Ziegeler
Adobe
cziegeler@apache.org