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

[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 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  
>> 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
>

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

[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 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  
> 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

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

[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 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

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

[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 Jackrabbit uses nt:unstructured for the
> jcr:content node [1] however Sling integration changes the default to
> 'nt:resource' [2]. Not sure why they differ. But changing here should
> be simply specifying a new OSGi config or changing the default OSGi
> config.
> 
> I know its case by case basis change but I am not able to figure out
> any easy way out here :(
> 

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.

I fear we're creating a monster of configurations here and there,
although the problem itself can be easily solved at the base.

Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

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

[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 the
jcr:content node [1] however Sling integration changes the default to
'nt:resource' [2]. Not sure why they differ. But changing here should
be simply specifying a new OSGi config or changing the default OSGi
config.

I know its case by case basis change but I am not able to figure out
any easy way out here :(

Chetan Mehrotra
[1] 
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/io/DefaultHandler.java#L112
[2] 
https://github.com/apache/sling/blob/trunk/bundles/jcr/webdav/src/main/java/org/apache/sling/jcr/webdav/impl/handler/DefaultHandlerService.java#L78

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

[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 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 relying on user to pass the hint and
> remember yet another optimization flag. If this change causes issue
> and user want old behavior a config switch can be provided for that
> 
> As mentioned earlier changing the default at Oak level is not possible
> as changing the nodetype semantics would break backward compatibility.
> While changing the nodetype used in some content structure created at
> Sling level should have lower impact and something which can be
> mitigated via config switch
> Chetan Mehrotra
> 
> 
> On Mon, Oct 3, 2016 at 5:37 PM, Carsten Ziegeler  wrote:
>> 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 user would have to
>>> specify that nodetype hint if he wants to use the oak:Resource
>>> nodetype?
>>
>> Which should be doable today - same would be true for oak:unstructured
>> (vs nt:unstructured). So I think there is nothing to be done in Sling.
>>
>> Regards
>> Carsten
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>>
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

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

[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 relying on user to pass the hint and
remember yet another optimization flag. If this change causes issue
and user want old behavior a config switch can be provided for that

As mentioned earlier changing the default at Oak level is not possible
as changing the nodetype semantics would break backward compatibility.
While changing the nodetype used in some content structure created at
Sling level should have lower impact and something which can be
mitigated via config switch
Chetan Mehrotra


On Mon, Oct 3, 2016 at 5:37 PM, Carsten Ziegeler  wrote:
> 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 user would have to
>> specify that nodetype hint if he wants to use the oak:Resource
>> nodetype?
>
> Which should be doable today - same would be true for oak:unstructured
> (vs nt:unstructured). So I think there is nothing to be done in Sling.
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

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

[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 user would have to
> specify that nodetype hint if he wants to use the oak:Resource
> nodetype?

Which should be doable today - same would be true for oak:unstructured
(vs nt:unstructured). So I think there is nothing to be done in Sling.

Regards
Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

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

[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 referenceable/orderable once then its
not possible to change the semantics later as it would break down
those code which rely on that semantic.

However user of the api can decide to use a different nodetype as per
his requirement. So its more like the api user deciding to switch a
more performant nodetype with the understanding around what that
nodetype guarantees (think of using ArrayList instead of LinkedList
depending on usage pattern).

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 user would have to
specify that nodetype hint if he wants to use the oak:Resource
nodetype?

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

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

[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 of type nt:resource. So far my reading of code is that code does
> not rely on specific nodetype but just that node name is 'jcr:content'
> as that is defined in nt:file nodetype definition itself
> 

Hmm, ok  - in general this is nothing Sling should deal with. I think if
oak:Resource is the better option, why can't do Oak the right thing?
Why do we have to add workarounds on top in Sling? And if someone is not
using the post servlet then it's again nt:Resource.

Carsten
-- 

Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

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

[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 reading of code is that code does
not rely on specific nodetype but just that node name is 'jcr:content'
as that is defined in nt:file nodetype definition itself

Chetan Mehrotra

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

[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 the patch then
> 

And then all scripts or code dealing with nt:resource fails as the node
or resource type is now oak:resource ?


 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

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

[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)

[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
 wrote:
> 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 current issue that we are discussing.
> Something which require wider effort! In this thread I would prefer to
> focus on the issue at hand and determine the approach to take.
>
>> When using special Oak nodetypes (and moving further away from JCR) we should
> stop claiming to be a web framework  using JCR but Oak.
>
> That may be one option as authentication layer depends on how Oak
> authentication works. But if we want to stick to JCR we can define our
> own nodetype and use that and not rely on Oak specific nodetype
> (Option #3)
>
> Chetan Mehrotra

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

[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 current issue that we are discussing.
Something which require wider effort! In this thread I would prefer to
focus on the issue at hand and determine the approach to take.

> When using special Oak nodetypes (and moving further away from JCR) we should
stop claiming to be a web framework  using JCR but Oak.

That may be one option as authentication layer depends on how Oak
authentication works. But if we want to stick to JCR we can define our
own nodetype and use that and not rely on Oak specific nodetype
(Option #3)

Chetan Mehrotra

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

[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 an ideal world probably yes. That would require decent amount of
refactoring of existing code. Current code already uses JCR nodetypes,
just that it inlines the constant names and does not have a direct
dependency on the API

In real world I am looking for least intrusive change here :)

Chetan Mehrotra

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

[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 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.

WDYT? Is that possible? Would it break backwards compatibility?

Regards
Julian


On Mon, Oct 3, 2016 at 7:23 AM, Chetan Mehrotra
 wrote:
> Hi Team,
>
> 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
>
> Chetan Mehrotra

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

[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
> hence the need for defining a custom nodetype

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.

When using special Oak nodetypes (and moving further away from JCR) we should 
stop claiming to be a web framework  using JCR but Oak.

Regards,
O.

> Chetan Mehrotra
> [1] http://markmail.org/thread/uj2ht4jwdrck7eja
> 
> On Mon, Oct 3, 2016 at 1:20 PM, Oliver Lietz  wrote:
> > 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 using implementation specific nodetypes I would like to stick
> > to JCR spec and expect the Jackrabbit/Oak team (togehter with other
> > implementers) to evolve the spec to version 3.
> > 
> > See also "jcr 2.0 spec url" on users@jackrabbit – is JCR dead?
> > 
> > Regards,
> > O.
> > 
> >> Chetan Mehrotra

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

[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] http://markmail.org/thread/uj2ht4jwdrck7eja


On Mon, Oct 3, 2016 at 1:20 PM, Oliver Lietz  wrote:
> 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 using implementation specific nodetypes I would like to stick to
> JCR spec and expect the Jackrabbit/Oak team (togehter with other implementers)
> to evolve the spec to version 3.
>
> See also "jcr 2.0 spec url" on users@jackrabbit – is JCR dead?
>
> Regards,
> O.
>
>> Chetan Mehrotra
>

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

[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 using implementation specific nodetypes I would like to stick to 
JCR spec and expect the Jackrabbit/Oak team (togehter with other implementers) 
to evolve the spec to version 3.

See also "jcr 2.0 spec url" on users@jackrabbit – is JCR dead?

Regards,
O.

> Chetan Mehrotra