Good question, I think a caller of create *should* provide a resource
type. The provider *must* use the type if provided. If it is not
provided, the provider *should* use some default (nt:unstructured for
JCR), but might refuse to create the resource.
While I would love to say the caller of create *must* provide the
resource type, I have the feeling that this will break existing code.
Regards
Carsten
On 12.05.2025 20:16, Konrad Windszus wrote:
Thanks for the response Carsten. As the resource type is mandatory does that
also imply that every ResourceResolver.create(…) must contain at least one
property (sling:resourceType) with a valid value?
Or how should the resource type be determined for newly created resources?
Thanks,
Konrad
On 10. May 2025, at 17:28, Carsten Ziegeler <cziege...@apache.org> 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
cziege...@apache.org
--
Carsten Ziegeler
Adobe
cziege...@apache.org
