Re: Oak 1.5.6 release plan

[Davide Giannella]

On 19/07/2016 11:45, Davide Giannella wrote:
> Hello team,
>
> I'm planning to cut Oak 1.5.6 today in the afternoon british time.
>
>
I've been trying quite long but the upload process always fails on
various module with HTTP timeout. Probably a network issue on my side.

Should have already reverted what was needed and will re-try from
scratch tomorrow.

Cheers
Davide

Re: Why is nt:resource referencable?

[Angela Schreiber]

Hi Chetan

That would be really troublesome for multiple reasons.

First of all nt:resource doesn't allow for residual properties as
it comes with defined set of property definitions. So, any attempt
to write a jcr:uuid property to such a node will fail.

Second, for other nodes that allow for residual properties (such as
e.g. oak:Unstructured), the declaring node type for such an jcr:uuid
property and thus the property definition itself would change
leading to very nasty problems, when you later try to add
mix:referenceable mixin type.

See e.g. OAK-2164, JCR-2779, OAK-2121, OAK-2246 (and maybe more).
So far our claim has always been that jcr:uuid is a reserved
property that must never be used for any other property than
the autocreated, mandatory, protected property defined by
mix:referenceable.

Really, I don't think that this would be feasible...
and just for the record: I am pretty sure that there was good
intention behind the change in nt-definition between JCR 1.0 and
JCR 2.0... but maybe not fully thought through when it comes to
backwards compatibility and I am sure that we would have changed
it when moving to Jackrabbit 2.x if that had worked.

Kind regards
Angela

On 20/07/16 12:53, "Chetan Mehrotra"  wrote:

>On Wed, Jul 20, 2016 at 4:04 PM, Marcel Reutegger 
>wrote:
>> Maybe we would keep the jcr:uuid property on the referenceable node and
>>add
>> the mixin?
>
>What if we do not add any mixin and just have jcr:uuid property
>present. The node would anyway be indexed so search would still work.
>Not sure if API semantics require that nodes lookedup by UUID have to
>be referenceable.
>
>For now I think oak:Resource is safest way. But just exploring other
>options if possible!
>
>
>Chetan Mehrotra

Re: Why is nt:resource referencable?

[Marcel Reutegger]

Hi,

On 20/07/16 12:53, Chetan Mehrotra wrote:

What if we do not add any mixin and just have jcr:uuid property
present. The node would anyway be indexed so search would still work.


that only works to some degree. there would be no property definition
for the jcr:uuid property and should be considered malformed. Changing
such a node would probably fail later, because the Oak type validator
complains about it.

Regards
 Marcel

Re: Why is nt:resource referencable?

[Chetan Mehrotra]

On Wed, Jul 20, 2016 at 4:04 PM, Marcel Reutegger  wrote:
> Maybe we would keep the jcr:uuid property on the referenceable node and add
> the mixin?

What if we do not add any mixin and just have jcr:uuid property
present. The node would anyway be indexed so search would still work.
Not sure if API semantics require that nodes lookedup by UUID have to
be referenceable.

For now I think oak:Resource is safest way. But just exploring other
options if possible!


Chetan Mehrotra

Re: Why is nt:resource referencable?

[Marcel Reutegger]

Hi,

On 20/07/16 11:41, Chetan Mehrotra wrote:

@Marcel - I did not understood JCR-2170 properly. But any chance we
can switch to newer version of nt:resource and do not modify existing
nodes and let the new definition effect/enforced only on new node.


node types are not versioned, which means all nodes with a given
jcr:primaryType refer to the same node type. either nt:resource extends
from mix:referenceable or it doesn't. as mentioned already, the issue
is with how to upgrade existing content. if we change nt:resource to
not extend from mix:referenceable anymore, we need an upgrade path.
just removing the jcr:uuid property on those nodes is trivial, but
what if there are nodes referencing them? Maybe we would keep the 
jcr:uuid property on the referenceable node and add the mixin?


Then there is the question of backward compatibility for code written
against JCR 1.0 and Jackrabbit 2.x / Oak 1.x behaviour, assuming 
nt:resource is always mix:referenceable.


Regards
 Marcel

Re: Why is nt:resource referencable?

[Angela Schreiber]

Hi Chetan

I would not do that even if it was possible as it will break
every single application that relies on nt:resource to extend
from mix:referenceable... these applications would need to change
their code adding the mixin manually which may lead to follow
up issues, because adding a mixin by specification requires
different privileges than creating a node with just a name where
the primary type (in this case nt:resource) was the applicable node
type selected by the system.

I don't see anything wrong with introducing oak:Resource and let
application developers decide on which variant they prefer.

Kind regards
Angela

On 20/07/16 11:41, "Chetan Mehrotra"  wrote:

>On Wed, Jul 20, 2016 at 2:49 PM, Bertrand Delacretaz
> wrote:
>> but the JCR spec (JSR 283 10 August 2009) only has
>>
>>   [nt:resource] > mix:mimeType, mix:lastModified
>> primaryitem jcr:data
>> - jcr:data (BINARY) mandatory
>
>Thats interesting. Did not knew its not mandated in JCR 2.0. However
>looks like for backward compatibility we need to support it. See [1]
>where this was changed
>
>@Marcel - I did not understood JCR-2170 properly. But any chance we
>can switch to newer version of nt:resource and do not modify existing
>nodes and let the new definition effect/enforced only on new node.
>
>Chetan Mehrotra
>[1] 
>https://issues.apache.org/jira/browse/JCR-2170?focusedCommentId=12754941
>age=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comme
>nt-12754941

Re: OAK SOLR re-index via index manager UI

[Tommaso Teofili]

Hi Sri,

Index Manager is not part of Apache Jackrabbit Oak, so this is not the
proper channel to get answers on that topic.

Regards,
Tommaso

Il giorno mer 20 lug 2016 alle ore 11:54 sri vaths
 ha scritto:

> Hi,We are not able to see the solr index for an re-index trigger via AEM
> 6.1 tools UI OAK index manager
>
> /libs/granite/operations/content/diagnosis/tool.html/_granite_oakindexmanager
>
> will the above UI only pick the direct index configuration under the
> /oak:index root node.
> We have placed the /oak:index node under specific content trees so that we
> need to index the entire that specific tree
> /content/sample/oak:index/solrIndex
>
> But this is not getting listed in the re-index UI
> Any idea how to bring specific paths to re-index UI
> with regardsSri

OAK SOLR re-index via index manager UI

[sri vaths]

Hi,We are not able to see the solr index for an re-index trigger via AEM 6.1 
tools UI OAK index manager
/libs/granite/operations/content/diagnosis/tool.html/_granite_oakindexmanager

will the above UI only pick the direct index configuration under the /oak:index 
root node.
We have placed the /oak:index node under specific content trees so that we need 
to index the entire that specific tree
/content/sample/oak:index/solrIndex

But this is not getting listed in the re-index UI
Any idea how to bring specific paths to re-index UI 
with regardsSri

Re: Internals of Apache Jackrabbit OAK repository & OOTB SOLR indexing

[sri vaths]

Thanks Michael for the slide share links will look into it. 

On Wednesday, 20 July 2016 12:33 PM, sri vaths  
wrote:
 

 Hi All,
Please share details on how OAK repository triggers node updates to SOLR for 
indexing, guessing it based on the OAK NodeState model but not sure how the 
flow happens.http://jackrabbit.apache.org/oak/docs/architecture/nodestate.html 
And also want to know the list of node states the index updates can happen to 
SOLR 
with regardsSri

  

Re: Why is nt:resource referencable?

[Chetan Mehrotra]

On Wed, Jul 20, 2016 at 2:49 PM, Bertrand Delacretaz
 wrote:
> but the JCR spec (JSR 283 10 August 2009) only has
>
>   [nt:resource] > mix:mimeType, mix:lastModified
> primaryitem jcr:data
> - jcr:data (BINARY) mandatory

Thats interesting. Did not knew its not mandated in JCR 2.0. However
looks like for backward compatibility we need to support it. See [1]
where this was changed

@Marcel - I did not understood JCR-2170 properly. But any chance we
can switch to newer version of nt:resource and do not modify existing
nodes and let the new definition effect/enforced only on new node.

Chetan Mehrotra
[1] 
https://issues.apache.org/jira/browse/JCR-2170?focusedCommentId=12754941=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12754941

Re: Why is nt:resource referencable?

[Angela Schreiber]

Hi Bertrand

It used to be mix:referenceable in JSR170 (i.e. JCR 1.0) and we
kept it for backwards compatibility:

https://docs.adobe.com/content/docs/en/spec/jcr/1.0/6.7.22.9_nt_resource.ht
ml

So, adding oak:Resource sounds the right thing to do here.

Kind regards
Angela

On 20/07/16 11:19, "Bertrand Delacretaz"  wrote:

>Hi,
>
>OAK-4567 introduces a new oak:Resource nodetype as an alternative to
>nt:resource which has mix:referenceable.
>
>I understand the idea of making that node non-referencable for
>performance reasons, but why is nt:resource referenceable in the first
>place?
>
>builtin_nodetypes.cnd [1] has this definition
>
>  [nt:resource] > mix:mimeType, mix:lastModified, mix:referenceable
>primaryitem jcr:data
>- jcr:data (BINARY) mandatory
>
>but the JCR spec (JSR 283 10 August 2009) only has
>
>  [nt:resource] > mix:mimeType, mix:lastModified
>primaryitem jcr:data
>- jcr:data (BINARY) mandatory
>
>Introducing a new nodetype leaks into applications, removing the
>default mix:referenceable mixin on nt:resource would be much simpler
>(at the cost of a migration tool probably), and people can always
>re-add the mixin if they really need it.
>
>WDYT?
>
>-Bertrand
>
>[1] 
>http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/res
>ources/org/apache/jackrabbit/oak/plugins/nodetype/write/builtin_nodetypes.
>cnd

Why is nt:resource referencable?

[Bertrand Delacretaz]

Hi,

OAK-4567 introduces a new oak:Resource nodetype as an alternative to
nt:resource which has mix:referenceable.

I understand the idea of making that node non-referencable for
performance reasons, but why is nt:resource referenceable in the first
place?

builtin_nodetypes.cnd [1] has this definition

  [nt:resource] > mix:mimeType, mix:lastModified, mix:referenceable
primaryitem jcr:data
- jcr:data (BINARY) mandatory

but the JCR spec (JSR 283 10 August 2009) only has

  [nt:resource] > mix:mimeType, mix:lastModified
primaryitem jcr:data
- jcr:data (BINARY) mandatory

Introducing a new nodetype leaks into applications, removing the
default mix:referenceable mixin on nt:resource would be much simpler
(at the cost of a migration tool probably), and people can always
re-add the mixin if they really need it.

WDYT?

-Bertrand

[1] 
http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/resources/org/apache/jackrabbit/oak/plugins/nodetype/write/builtin_nodetypes.cnd

Re: Internals of Apache Jackrabbit OAK repository & OOTB SOLR indexing

[Michael Marth]

Some presentations that might also be of interest in this context:

http://de.slideshare.net/teofili/oak-solr-integration
http://de.slideshare.net/teofili/scaling-search-in-oak-with-solr
http://de.slideshare.net/teofili/flexible-search-oakmin

Cheers
Michael



On 20/07/16 09:55, "Michael Marth"  wrote:

>Hi,
>
>Are you aware of this docu: 
>http://jackrabbit.apache.org/oak/docs/query/solr.html
>?
>It points to some of the relevant classes.
>
>Cheers
>Michael
>
>
>
>On 20/07/16 09:03, "sri vaths"  wrote:
>
>>Hi All,
>>Please share details on how OAK repository triggers node updates to SOLR for 
>>indexing, guessing it based on the OAK NodeState model but not sure how the 
>>flow 
>>happens.http://jackrabbit.apache.org/oak/docs/architecture/nodestate.html 
>>And also want to know the list of node states the index updates can happen to 
>>SOLR 
>>with regardsSri

Re: Internals of Apache Jackrabbit OAK repository & OOTB SOLR indexing

[Michael Marth]

Hi,

Are you aware of this docu: 
http://jackrabbit.apache.org/oak/docs/query/solr.html
?
It points to some of the relevant classes.

Cheers
Michael



On 20/07/16 09:03, "sri vaths"  wrote:

>Hi All,
>Please share details on how OAK repository triggers node updates to SOLR for 
>indexing, guessing it based on the OAK NodeState model but not sure how the 
>flow happens.http://jackrabbit.apache.org/oak/docs/architecture/nodestate.html 
>And also want to know the list of node states the index updates can happen to 
>SOLR 
>with regardsSri

Internals of Apache Jackrabbit OAK repository & OOTB SOLR indexing

[sri vaths]

Hi All,
Please share details on how OAK repository triggers node updates to SOLR for 
indexing, guessing it based on the OAK NodeState model but not sure how the 
flow happens.http://jackrabbit.apache.org/oak/docs/architecture/nodestate.html 
And also want to know the list of node states the index updates can happen to 
SOLR 
with regardsSri