Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-04 Thread Chetan Mehrotra
Okie. So I have started a new mail thread addressing both project teams to see if we can converge on some agreement here. Kindly provide your feedback there Chetan Mehrotra On Tue, Oct 4, 2016 at 11:55 AM, Carsten Ziegeler wrote: > Thanks Chetan, > > I'm really wondering

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-04 Thread Carsten Ziegeler
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

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-04 Thread Chetan Mehrotra
On Tue, Oct 4, 2016 at 11:01 AM, Carsten Ziegeler 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

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Carsten Ziegeler
Chetan Mehrotra wrote > On Mon, Oct 3, 2016 at 9:37 PM, Carsten Ziegeler wrote: >> For example, if you drop a file through webdav, I assume it's still >> nt:Resource. > > Had a look at the Webdav stuff and story here looks interesting. The > default implementation in

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
On Mon, Oct 3, 2016 at 9:37 PM, Carsten Ziegeler wrote: > For example, if you drop a file through webdav, I assume it's still > nt:Resource. Had a look at the Webdav stuff and story here looks interesting. The default implementation in Jackrabbit uses nt:unstructured for

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Carsten Ziegeler
But again, if you're not using the post servlet, you're not benefiting For example, if you drop a file through webdav, I assume it's still nt:Resource. Carsten Chetan Mehrotra wrote > Logic to create a file structure is very much baked in the code so not > possible to influence that currently

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
Logic to create a file structure is very much baked in the code so not possible to influence that currently i.e. specify a different node for jcr:content node of nt:file. So would need some change in Sling Though IMHO I would change the default logic to use a non referenceable node and avoid

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Carsten Ziegeler
Chetan Mehrotra wrote > > That being said then same argument can be applied to change being done > in Sling level where for same POST request now results in different > nodetypes being used. If that is a big concern then we can make use of > this new nodetype based on some request param. So a

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
On Mon, Oct 3, 2016 at 3:43 PM, Carsten Ziegeler wrote: > why can't do Oak the right thing? Compatibility constraints :). Had this discussion earlier also but given compatibility constraints its not possible to change the defaults. If a nodetype says its

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Carsten Ziegeler
Chetan Mehrotra wrote > On Mon, Oct 3, 2016 at 3:30 PM, Carsten Ziegeler wrote: >> And then all scripts or code dealing with nt:resource fails as the node >> or resource type is now oak:resource ? > > Yes if the code checks if nodetype of jcr:content node under nt:file > is

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
On Mon, Oct 3, 2016 at 3:30 PM, Carsten Ziegeler wrote: > And then all scripts or code dealing with nt:resource fails as the node > or resource type is now oak:resource ? Yes if the code checks if nodetype of jcr:content node under nt:file is of type nt:resource. So far my

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Carsten Ziegeler
Chetan Mehrotra wrote > On Mon, Oct 3, 2016 at 2:43 PM, Julian Sedding wrote: >> Actually, the Sling POST Servlet bundle has a dependency on the JCR >> API, as does SlingFileUploadHandler. > > Aah missed seeing that. Makes decision simpler then. Would try to come > up with

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
On Mon, Oct 3, 2016 at 2:43 PM, Julian Sedding wrote: > Actually, the Sling POST Servlet bundle has a dependency on the JCR > API, as does SlingFileUploadHandler. Aah missed seeing that. Makes decision simpler then. Would try to come up with the patch then Chetan Mehrotra

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Julian Sedding
Actually, the Sling POST Servlet bundle has a dependency on the JCR API, as does SlingFileUploadHandler. In that case #2 seems the best way forward. Use oak:Resource if available, otherwise fall back to nt:resource. Regards Julian On Mon, Oct 3, 2016 at 10:49 AM, Chetan Mehrotra

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
On Mon, Oct 3, 2016 at 2:01 PM, Oliver Lietz wrote: > I'm aware of that thread and therefore suggest to drive the spec towards > version 3. Providing tools for upgrading from 2 to 3 would allow to break > backwards compatibility and evolve. I believe this is orthogonal to

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
On Mon, Oct 3, 2016 at 2:06 PM, Julian Sedding wrote: > In an ideal world I would decouple the logic of what constitutes a > file, i.e. create an API/convention in Sling, that is JCR agnostic and > move the JCR-specific implementation to the JCR ResourceProvider > bundle. In

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Julian Sedding
Hi Chetan I think point #2 (cannot check for oak:Resource nodetype because Sling POST Servlet has no JCR dependency) indicates that we have an abstraction leak. I.e. the POST servlet needs to know the correct JCR node-structure despite the fact that it "officially" has no JCR dependency. In an

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Oliver Lietz
On Monday 03 October 2016 13:43:44 Chetan Mehrotra wrote: > Hi Oliver, Hi Chetan, > Defaults for nt:resource was changed in JCR 2.0 and it was made > unreferenceable. See [1] for some background. However JR2 and then Oak > continued to use the older definition for compatibility purpose and >

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Chetan Mehrotra
Hi Oliver, Defaults for nt:resource was changed in JCR 2.0 and it was made unreferenceable. See [1] for some background. However JR2 and then Oak continued to use the older definition for compatibility purpose and hence the need for defining a custom nodetype Chetan Mehrotra [1]

Re: Use oak:Resource nodetype instead of nt:resource while creating file node structure (SLING-6090)

2016-10-03 Thread Oliver Lietz
On Monday 03 October 2016 10:53:40 Chetan Mehrotra wrote: > Hi Team, Hi Chetan, > Have a look at SLING-6090 where its suggested to avoid using > nt:resource. It also mentions few possible solutions. > > Kindly have a look and provide your feedback on which solution to implement rather than