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 <[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]
--
Carsten Ziegeler
Adobe
[email protected]
