Thanks Chetan, I'm really wondering if there can't be a better solution :)
For example, look at the jcr classloader module, writing class files to the repository. It creates a nt:file with a nt:resource child node. While jcr classloader is not that important nowadays anymore, I think we have several of those places in our code base. I understand that we don't have to change all those places, but I assume the optimum would be that whenever such a jcr:content child node is created, you use oak:resource as the node type - unless there is a really good reason to make it referencable. But being realistic, has there ever been a use case for this? While we could change the post servlet and add the check, I definitely don't want to add such a check all over our code base, then thinking of our downstream users, they would have to do the same. Carsten Chetan Mehrotra wrote > On Tue, Oct 4, 2016 at 11:01 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> What about if the node type is changed by default in Oak? This seems to >> be according to the spec. >> The problem might then only be with old installations and for this you >> can provide a switch. Maybe somehow even detecting the situation. > > This has been discussed earlier also [1]. Also concern was raised in > spec update itself [2] that such a change is backward incompatible. > Its like changing an existing interface. So any code which rely on > nt:resource being referenceable would fail. Remember any change in > nodetype definition is global. > > Changing at Sling Level > ================== > > Change here would be more manageable. Per spec nt:file would have a > child node which is having name 'jcr:content'. Spec does not mandates > any nodetype for this. It can be nt:resource, nt:unstructured or > oak:Resource. [3] > > ---------------- > ... requires a single child node called jcr:content. The jcr:content > node is used to hold the actual content of the file. This child node > is mandatory, but not auto-created. Its node type will be > application-dependent and therefore it must be added by the client. > ---------------- > > So application is free to choose the nodetype for jcr:content node > > Config Complexity > ================== > >> I fear we're creating a monster of configurations here and there > > Lets see. Proposal here is to change the defaults > > 1. Have webdav use oak:Resource as default if repository has that nodetype > 2. Have SlingPostServlet use oak:Resource as default if repository has > that nodetype - a config switch to revert back to old behaviour if > application code relies on fact that 'jcr:content' node in nt:file is > always of type nt:resource > > In both cases the end user does not have to change any default setting > unless required. > >> although the problem itself can be easily solved at the base. > > Had compatibility been not a concern that would have been an option. > However as explained above doing that would be a backward incompatible > global change. While changes being proposed are valid per spec > (jcr:content can be any nodetype) and change is much more controlled > (config switches to revert back to old behaviour in case) and is > scoped to Sling part > > Its just like StringBuilder is better than StringBuffer in most cases > but even then it was introduced as a new class and semantics of > StringBuffer were not changed :) > > To reiterate I am just aiming for a solution here which enables a user > to use a more optimum nodetype and get best performance out of > underlying repository. > > Chetan Mehrotra > [1] http://markmail.org/thread/uj2ht4jwdrck7eja > [2] https://java.net/jira/browse/JSR_283-428 > [3] https://docs.adobe.com/content/docs/en/spec/jcr/1.0/6.7.22.6_nt_file.html > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
