Hi Jason Both the "sling:resourceType" and "jcr:primaryType" property names used to derive the resource type of a resource (i.e. Resource.getResourceType()) are implementation details of the JCR Resource Provider (see [0]). For a JCR Resource Provide this seems like a legitimate choice. If, however, generic (or JCR agnostic) parts of Sling were to implement this fallback, that would be incorrect - I agree with that.
Regarding the fact that Resource.getResourceType() may not return null; there is the catch-all resource type "sling/servlet/default" - this is equivalent to Object in Java. So here we go, we have a Sling type-system in the makings ;) Hope this helps clear up some misunderstandings. Regards Julian [0] https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L117 On Thu, Nov 1, 2018 at 7:04 PM Jason E Bailey <j...@apache.org> wrote: > > > > > Just to try and understand this better - you're saying that instead of > > Sling falling back to the jcr:primaryType property in case of JCR > > resources, the JCR resource provider should instead synthesize that > > property itself, even if it does not exist? > > > > Robert > > > > Right now there is an inconsistency between resources that are in the jcr and > resources that are in other resource providers. That inconsistency is that > all jcr resources have a jcr:primaryType. This is understandable because the > jcr has a Type system and there is a defined hierarchy of types in the jcr > that all lead back to nt:base. > > The fact that there is always a type is exploited by the ResourceResolver so > that it falls back to checking the jcr:primaryType if there is no > resourceType. This becomes problematic with ResourceProviders because > initially, there was never a requirement for them to provide either. > > There has been talk recently about creating a type system for resources. > https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements. > For there to be a proper type system you need to have a Type hierarchy. > > Right now the getResourceType no longer allows you to return null, so it must > return something, if you're creating a resource provider that could be a > value that represents a "fake" resource. In a type system that doesn't make > sense. > > If we implement a Sling Resource Type system we will be left with two options > 1. All resources must have a valid sling:resourceType associated with it > 2. Or consider a default sling:resourceType if none is present. > > -Jason
