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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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]
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
20 matches
Mail list logo