Backport of OAK-4933 to 1.6

[Raul-Nicolae Hudea]

Hi,

I would like to backport OAK-4933 to 1.6. The impact should be minimal since 
the changes are about bringing the AzureBlobStore connector to 1.6.

Changes are:
- new module
- changes in oak-run to support the azure data store

Thanks,
Raul

Re: New JIRA component for observation

[Chetan Mehrotra]

On Mon, Mar 27, 2017 at 12:56 PM, Marcel Reutegger  wrote:
> In my view this indicates that the existing modules should probably be split
> and we'd be back to a 1:1 relation between modules in SVN and components in
> JIRA. Alternatively, we could also use JIRA labels and group issues by
> features like observation.

For now I prefer a logical separation in JIRA issues. Compared to
label the components have better in built support in JIRA ui like
open/closed/aging reports, drop down etc. So it would be better to use
components over label for such distinct features in Oak.

Chetan Mehrotra

Re: New JIRA component for observation

[Michael Dürig]

On 27.03.17 09:26, Marcel Reutegger wrote:

I'm wondering if this is the best approach. Initially we used the JIRA
component 1:1 for modules we have in SVN. Now we also use them for
sub-modules like 'documentmk', 'mongomk', 'property-index', ...


+1

Michael

Re: New JIRA component for observation

[Marcel Reutegger]

Hi,

I'm wondering if this is the best approach. Initially we used the JIRA 
component 1:1 for modules we have in SVN. Now we also use them for 
sub-modules like 'documentmk', 'mongomk', 'property-index', ...


In my view this indicates that the existing modules should probably be 
split and we'd be back to a 1:1 relation between modules in SVN and 
components in JIRA. Alternatively, we could also use JIRA labels and 
group issues by features like observation.


Regards
 Marcel

On 27/03/17 07:57, Chetan Mehrotra wrote:

I analyzed the issues currently logged under component "core" which
has ~100 issues. Looking at most issues I think we can do following

1. Create a new component for observation issues i.e. "observation"
2. Avoid marking same issue for multiple component like "documentmk
and core" unless the change impacts code base outside of that
component like in this case outside of documentmk package

This would ensure that we can get some better sense out of issues
currently clubbed under "core"

Thoughts?

Chetan Mehrotra

R: problem on oak jcr sql2 query

[Ancona Francesco]

Sorry.

We are using Oak 1.4.10 and solr 4.10.4

i send you also a pdf example: the searched word is "sezione"

In another document ([nt:file] that doesn't have childs) i'd want match only 
through metadata that contains the word "company"

Actually  i resolved the problem executing a query like this: select p.* from 
[nt:base] as p where .. contains (p.*, "company") or contains (p.*, 
"sezione")

Then i explore (programmatically and after the query response) jcr nodes to set 
only nodes that are [nt:file]

Is it the correct approach ?

Thanks in advance,
best regards

-Messaggio originale-
Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] 
Inviato: venerdì 24 marzo 2017 14:56
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone 
Oggetto: Re: problem on oak jcr sql2 query

It'd be helpful to also know the version of Oak and Solr you're using and, 
possibly, sample content you expect the query to match.

Thanks,
Tommaso


Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller  ha 
scritto:

> Could you post the index definition please?
>
>
> From: Ancona Francesco 
> Reply-To: "oak-dev@jackrabbit.apache.org" 
> 
> Date: Thursday, 23 March 2017 at 15:19
> To: "oak-dev@jackrabbit.apache.org" 
> Cc: Diquigiovanni Simone 
> Subject: problem on oak jcr sql2 query
>
> Hi all,
> we use SolrSrerver for fulltext searches; both on metadata both on 
> content binary.
> In general i have to find all nodes nt:file that contain the word 
> “company” or all nodes that have childs nt:resource that contain the 
> same word.
>
> Unfortunately if upload e file (so a node that is a nt:resource) and i 
> use this query SELECT p.* FROM [nt:file] as p where 
> contains(p.*,''company ')
>
> Solr find result  but the RowIterator doesn’t return anything.
>
> Instead the above query works
> SELECT p.* FROM [nt:resource] as p where contains(p.*,'company') But 
> doesn’t find nt:file nodes
>
> Can you help me ?
>
> Thanks in advance.
>
>
> [cid:image002.png@01D2A3E8.D7747740]
> Francesco Ancona | Software Dev. Dept. (SP) - Software Architect tel. 
> +39 049 8979797 <049%20897%209797> | fax +39 049 8978800 
> <049%20897%208800> | cel. +39 3299060325 <329%20906%200325>
> e-mail: francesco.anc...@siav.it | www.siav.it<
> https://na01.safelinks.protection.outlook.com/?url=www.siav.it=02
> %7C01%7C%7Caed3cadf483741e2971708d471f7b284%7Cfa7b1b5a7b34438794aed2c1
> 78decee1%7C0%7C0%7C636258756051666135=GFXjC%2BgyoIh37AXmGYhYdORt
> Xp1dFiA5v0hoghgbtBw%3D=0
> >
>
> I contenuti di questa e-mail e dei suoi allegati sono confidenziali e 
> riservati esclusivamente ai destinatari.
> L'utilizzo per qualunque fine del presente messaggio e degli allegati 
> così come la relativa divulgazione senza l'autorizzazione del mittente 
> sono vietati.
> Se avete ricevuto questa e-mail per errore, vi preghiamo di 
> distruggerla e di comunicarcelo.
> I dati personali sono trattati esclusivamente per le finalità della 
> presente comunicazione in conformità con la legislazione vigente (D.lgs.
> 196/2003 "Codice Privacy").
> Per informazioni: SIAV S.p.A. – s...@siav.it – 049 8979797 
> <049%20897%209797>
>
> The contents of this e-mail and its attachments are confidential and 
> reserved exclusively to the recipients.
> The use for any purpose of this message and attachments as well as its 
> disclosure without the consent of the sender is prohibited.
> If you have received this email in error, please destroy it and notify us.
> Personal data shall be processed solely for the purposes of this 
> notice in accordance with current legislation (Legislative Decree no. 
> 196/2003 "Code").
> For more information: SIAV S.p.A. – s...@siav.it – 049 8979797 
> <049%20897%209797>
>
>

 
 

This footnote confirms that this email message has been scanned by PineApp 
Mail-SeCure for the presence of malicious code, vandals & computer viruses.

Re: Logger category org.apache.jackrabbit.oak.jcr.operations.writes includes 'refresh' operation

[Chetan Mehrotra]

Its a write operation as it has potential to change the session state.
If the refresh is done with keepChanges=false the current transient
changes would be discarded.
Chetan Mehrotra


On Fri, Mar 24, 2017 at 2:07 PM, Robert Munteanu  wrote:
> Hi,
>
> With Oak 1.6.1 I've enabled the
> org.apache.jackrabbit.oak.jcr.operations.writes logger to write on
> TRACE level, and I notice lots of 'refresh' operations. Is that
> expected? Looks to me more like a read operation than a write one.
>
> Robert