[jira] [Commented] (OAK-6773) Convert oak-store-composite to OSGi R7 annotations

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838076#comment-17838076
 ] 

Robert Munteanu commented on OAK-6773:
--

Thanks for the heads-up [~baedke]. I think the descriptions are valuable to 
developers, so keeping them as comments would be good.

> Convert oak-store-composite to OSGi R7 annotations
> --
>
> Key: OAK-6773
> URL: https://issues.apache.org/jira/browse/OAK-6773
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: composite
>Reporter: Robert Munteanu
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 1.64.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OAK-6741) Switch to official OSGi component and metatype annotations

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784910#comment-17784910
 ] 

Robert Munteanu commented on OAK-6741:
--

[~baedke] - when I created this issue OSGi R6 was the current release. I don't 
think we should target an old version of the annotations by default.

> Switch to official OSGi component and metatype annotations
> --
>
> Key: OAK-6741
> URL: https://issues.apache.org/jira/browse/OAK-6741
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: OAK-6741-proposed-changes-chetans-feedback.patch, 
> osgi-metadata-1.7.8.json, osgi-metadata-trunk.json
>
>
> We should remove the 'old' Felix SCR annotations and move to the 'new' OSGi 
> R6 annotations.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OAK-9841) Race condition in NodeStoreChecksService

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575812#comment-17575812
 ] 

Robert Munteanu commented on OAK-9841:
--

[~kwin] - I am not a big fan over that approach since it requires custom code, 
but if you think that this is the best approach we should go for it.

> Race condition in NodeStoreChecksService
> 
>
> Key: OAK-9841
> URL: https://issues.apache.org/jira/browse/OAK-9841
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: composite
>Reporter: Konrad Windszus
>Priority: Major
>
> The {{NodeStoreChecksService}} 
> (https://github.com/apache/jackrabbit-oak/blob/bbc141fd1fb9ff0d9ce742279445df9eb698c3e3/oak-store-composite/src/main/java/org/apache/jackrabbit/oak/composite/checks/NodeStoreChecksService.java#L41)
>  executes all bound {{MountedNodeStoreChecker}} s which have been there at 
> the time of activation.
> The references are not greedily referenced and also there is no wait for 
> specific {{MountedNodeStoreChecker}} services to be active.
> That leads to the fact that the usage of {{NodeStoreChecksService}} in 
> {{CompositeNodeStoreService.registerCompositeNodeStore(...)}} is not 
> deterministic as the starting order of OSGi services determine which 
> {{MountedNodeStoreChecker}} are active during 
> {{CompositeNodeStoreService.activate()}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OAK-9841) Race condition in NodeStoreChecksService

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17567997#comment-17567997
 ] 

Robert Munteanu commented on OAK-9841:
--

[~kwin] - I think the deployer is the one that should make this judgement. I 
wonder whether we can use the {{.target}} and {{.cardinality.minimum}} 
properties defined in 
https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e40380
 for this.

> Race condition in NodeStoreChecksService
> 
>
> Key: OAK-9841
> URL: https://issues.apache.org/jira/browse/OAK-9841
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: composite
>Reporter: Konrad Windszus
>Priority: Major
>
> The {{NodeStoreChecksService}} 
> (https://github.com/apache/jackrabbit-oak/blob/bbc141fd1fb9ff0d9ce742279445df9eb698c3e3/oak-store-composite/src/main/java/org/apache/jackrabbit/oak/composite/checks/NodeStoreChecksService.java#L41)
>  executes all bound {{MountedNodeStoreChecker}} s which have been there at 
> the time of activation.
> The references are not greedily referenced and also there is no wait for 
> specific {{MountedNodeStoreChecker}} services to be active.
> That leads to the fact that the usage of {{NodeStoreChecksService}} in 
> {{CompositeNodeStoreService.registerCompositeNodeStore(...)}} is not 
> deterministic as the starting order of OSGi services determine which 
> {{MountedNodeStoreChecker}} are active during 
> {{CompositeNodeStoreService.activate()}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (OAK-9433) TokenAuthentication.authenticate: throw specific exception for expired credentials

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346077#comment-17346077
 ] 

Robert Munteanu commented on OAK-9433:
--

[~angela] - thanks, this is exactly what I was thinking of.

> TokenAuthentication.authenticate: throw specific exception for expired 
> credentials 
> ---
>
> Key: OAK-9433
> URL: https://issues.apache.org/jira/browse/OAK-9433
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security, security-spi
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.40.0
>
> Attachments: OAK-9433.patch
>
>
> [~rombert] suggested to throw a specific exception upon 
> {{TokenAuthentication.authenticate}} in case the token credentials have 
> expired.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9433) TokenAuthentication.authenticate: throw specific exception for expired credentials

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345946#comment-17345946
 ] 

Robert Munteanu commented on OAK-9433:
--

Ack. This would be useful to detect an authentication failure as 'transient' in 
upper layers, e.g. when performing Sling authentication.

> TokenAuthentication.authenticate: throw specific exception for expired 
> credentials 
> ---
>
> Key: OAK-9433
> URL: https://issues.apache.org/jira/browse/OAK-9433
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jackrabbit-api, security
>Reporter: Angela Schreiber
>Assignee: Angela Schreiber
>Priority: Major
>
> [~rombert] suggested to throw a specific exception upon 
> {{TokenAuthentication.authenticate}} in case the token credentials have 
> expired.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-6758) Convert oak-authorization-cug to OSGi R6 annotations

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205426#comment-17205426
 ] 

Robert Munteanu commented on OAK-6758:
--

[~angela] - I think the PR overall looks good. There are unfortunately no great 
ways of checking automatically. What I can think of is comparing the bundle 
before and after the change, and making sure:

- the MANIFEST.MF files are equivalent
- the files under OSGI-INF/ are equivalent

Note that using `diff` will be useless, since the ordering of the tags and 
attributes in XML will be the different.

In addition to that, you can take advantage of the following:
- the {{@Reference}} annotation has a default cardinality of {{MANDATORY}}, so 
you don't need to specify it
- the property names are generated from the method names, so {{@Reference 
public void bindExclude}} would generate a name of _Exclude_ (note the 
uppercase). Not sure if it helps
- You can now pass typed objects to {{activated}} and {{modified}} methods, so 
for {{CugConfiguration}} you could write

{code:java}
protected void activate(Configuration cfg) {
  if ( cfg.cugEnabled() ) {...}
}
{code}

But I'm not sure that helps you further.

Hope this has been useful.

> Convert oak-authorization-cug to OSGi R6 annotations
> 
>
> Key: OAK-6758
> URL: https://issues.apache.org/jira/browse/OAK-6758
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: authorization-cug
>Reporter: Robert Munteanu
>Assignee: Angela Schreiber
>Priority: Major
> Fix For: 1.36.0
>
> Attachments: OAK-6758.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OAK-9208) Log unexpected writes to the paths designated as part of a non-default mount

[Robert Munteanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved OAK-9208.
--
Resolution: Fixed

> Log unexpected writes to the paths designated as part of a non-default mount
> 
>
> Key: OAK-9208
> URL: https://issues.apache.org/jira/browse/OAK-9208
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.36.0
>
>
> When populating a composite mount there are certain components that write 
> content to it. Some of them are declarative and make it easy to infer the 
> output, e.g. content package installer and Sling's repoinit.
> Others are unpredictable, such as OSGi components/activators.
> It would be useful to report such "unexpected" writes so that they can be 
> analysed and disabled. The analyser would get the mount information from the 
> {{MountInfoProvider}} and report:
> - when such writes occur
> - a stack trace of the write operation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (OAK-9208) Log unexpected writes to the paths designated as part of a non-default mount

[Robert Munteanu (Jira)]

Robert Munteanu created OAK-9208:


 Summary: Log unexpected writes to the paths designated as part of 
a non-default mount
 Key: OAK-9208
 URL: https://issues.apache.org/jira/browse/OAK-9208
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: composite
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: 1.36.0


When populating a composite mount there are certain components that write 
content to it. Some of them are declarative and make it easy to infer the 
output, e.g. content package installer and Sling's repoinit.

Others are unpredictable, such as OSGi components/activators.

It would be useful to report such "unexpected" writes so that they can be 
analysed and disabled. The analyser would get the mount information from the 
{{MountInfoProvider}} and report:

- when such writes occur
- a stack trace of the write operation



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098997#comment-17098997
 ] 

Robert Munteanu commented on OAK-9047:
--

FWIW, based on my experiments in Sling, it is crucial that the SecurityProvider 
is registered with all the correct dependencies from the start. Otherwise we 
will get an incorrect repository setup, even though temporarily, and invalid 
content willl be written to the nodestore

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098989#comment-17098989
 ] 

Robert Munteanu commented on OAK-9047:
--

Ack [~angela]

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098983#comment-17098983
 ] 

Robert Munteanu commented on OAK-9047:
--

[~angela] - I think the setup we should be looking at is "Oak with OSGi but not 
(Sling OR AEM)". I would venture to say that all OSGi-based deployments of Oak 
use either Sling or AEM. And yes, I made that up :-) but based on what I've 
seen.

Of course, you experience could be different and I very well may be wrong.

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098973#comment-17098973
 ] 

Robert Munteanu commented on OAK-9047:
--

That is a good point [~kwin]. In practice, everyone would be required to 
configure it, so the BC issue would exist in theory only ( /cc [~angela] )

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098947#comment-17098947
 ] 

Robert Munteanu commented on OAK-9047:
--

[~angela] - yes, right. That would happen when setting this policy for any 
component though.

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098938#comment-17098938
 ] 

Robert Munteanu commented on OAK-9047:
--

IIUC the root problem is that start components before configurations are 
applied. If we apply this policy to the SecurityProviderRegistration, it will 
only activate once the configurations are applied. It may be that I am wrong, I 
experimented this this some months ago.

[~angela] - the BC breakage is that existing deployments will need to add an 
explicit configuration, even if using the default values for the 
SecurityProviderRegistration.

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-9047) Make the DefaultAuthorizableActionProvider require a configuration

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098915#comment-17098915
 ] 

Robert Munteanu commented on OAK-9047:
--

If we decide to go down this route, I think the 
{{SecurityProviderRegistration}} should be the the one to have 
{{ConfigurationPolicy.REQUIRE}}, as it aggregates many (all?) of the 
security-related services.

> Make the DefaultAuthorizableActionProvider require a configuration
> --
>
> Key: OAK-9047
> URL: https://issues.apache.org/jira/browse/OAK-9047
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security-spi
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently configuring the {{DefaultAuthorizableActionProvider}} leads to 
> restart of the Oak repository in the context of 
> https://issues.apache.org/jira/browse/SLING-7811?focusedCommentId=16573171=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16573171.
>  
> It would make sense to only start the service 
> https://github.com/apache/jackrabbit-oak/blob/1f90e8c632868e658cc60b95bc5ec49182c4e173/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/action/DefaultAuthorizableActionProvider.java#L45
>  once a mandatory configuration is in place.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-8794) oak-solr-osgi does not build for Java 8 if Jackson libraries upgraded to 2.10.0

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16983305#comment-16983305
 ] 

Robert Munteanu commented on OAK-8794:
--

I think the safest way is to wait for the scr.bnd plugin release, and the 
update the tooling. In Sling we are versioning dependencies independetly in 
modules, but maybe in Oak it would be confusing as dependencies are generally 
centrally managed.

> oak-solr-osgi does not build for Java 8 if Jackson libraries upgraded to 
> 2.10.0
> ---
>
> Key: OAK-8794
> URL: https://issues.apache.org/jira/browse/OAK-8794
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Affects Versions: 1.20.0
>Reporter: Matt Ryan
>Priority: Major
>
> If the Jackson version in {{oak-parent/pom.xml}} is updated from 2.9.10 to 
> 2.10.0, we get a build failure in {{oak-solr-osgi}} if we try to build with 
> Java 8.
> This is blocking OAK-8105 which in turn is blocking OAK-8607 and OAK-8104.  
> OAK-8105 is about updating {{AzureDataStore}} to the Azure version 12 SDK 
> which requires Jackson 2.10.0.
> Would it be possible to update {{oak-parent/pom.xml}} to Jackson version 
> 2.10.0 and then specify 2.9.10 in {{oak-solr-osgi}}?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-8798) Upgrade maven-bundle-plugin to 4.2.1

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982433#comment-16982433
 ] 

Robert Munteanu commented on OAK-8798:
--

A good start with debugging would be to eliminate the maven-bundle-plugin 
configuration, which would presumably fix this. If it fixes it add back configs 
until you hit the problem. If it does not file a bug with bnd.

> Upgrade maven-bundle-plugin to 4.2.1
> 
>
> Key: OAK-8798
> URL: https://issues.apache.org/jira/browse/OAK-8798
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-8798.diff
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-8717) Remove deprecated Guava-based APIs

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959582#comment-16959582
 ] 

Robert Munteanu commented on OAK-8717:
--

I took a quick look in the latest sling starter, using 
http://localhost:8080/system/console/depfinder

- org.apache.jackrabbit.oak.commons.io, only used by oak-lucene
- org.apache.jackrabbit.oak.commons, used by oak bundles and 
{{org.apache.sling.jcr.base}}
- org.apache.jackrabbit.oak.commons.jmx, only used by oak bundles
- org.apache.jackrabbit.oak.spi.whiteboard, used by oak bundles and 
{{org.apache.sling.jcr.oak.server}}
- org.apache.jackrabbit.oak.spi.security.authentication.credentials, only used 
by oak-core

So for Sling the impact is limited to two bundles, and I think would be safe to 
widen the import ranges when this change is committed, so we get a drop-in Oak 
upgrade.

> Remove deprecated Guava-based APIs
> --
>
> Key: OAK-8717
> URL: https://issues.apache.org/jira/browse/OAK-8717
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Attachments: OAK-8717.diff
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958950#comment-16958950
 ] 

Robert Munteanu commented on OAK-7182:
--

It would be good to know which exported package versions are going to be 
increased to consider this "done". Then we can communicate a plan to remove 
such usages and make consumers compatible before the release, not after it.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (OAK-7739) Use an index only if a certain node or property exists

[Robert Munteanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reassigned OAK-7739:


Assignee: Thomas Mueller

> Use an index only if a certain node or property exists
> --
>
> Key: OAK-7739
> URL: https://issues.apache.org/jira/browse/OAK-7739
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.10.0, 1.9.9
>
>
> Currently, adding a new index (or reindexing) means the index is used for 
> queries as soon as indexing is finished. When using the composite node store 
> (in a blue-green deployment), it would be better if there is some control on 
> when the index is used for queries. Meaning, the index is used only if a 
> certain node or property exists. It is not used if the node or property 
> doesn't exist. That allows to control usage as follows:
> * Old (blue) version: node /library/version, property v1 does exist, but v2 
> does not.
> * New (green) version: node /library/version, property v1 does not exist, but 
> v2 does exist.
> Now a new index can be created which is not used with the old version, but 
> used with the new version. The index configuration is as follows:
> {noformat}
> /oak:index/foo_v2/@useIfExists = /library/version/@v2
> {noformat}
> Similary, an index is used only with the old, but not with the new version, 
> as follows:
> {noformat}
> /oak:index/foo_v1/@useIfExists = /library/version/@v1
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (OAK-8529) Deregister MBeans on SecurityProviderRegistration component deactivation

[Robert Munteanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved OAK-8529.
--
Resolution: Fixed

Thanks for the review,  [~angela]. I've applied the patch (with modified test 
name) in https://svn.apache.org/r1867103.

> Deregister MBeans on SecurityProviderRegistration component deactivation 
> -
>
> Key: OAK-8529
> URL: https://issues.apache.org/jira/browse/OAK-8529
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> The SecurityProviderRegistration is prone to being activated and deactivated 
> during a regular Sling application startup ( for a prolonged discussion see 
> SLING-7811 ). The instance should fully cleanup after itself to make sure it 
> will be usable after an activate/deactive cycle.
> In practice the MBeans remain registered and prevent a further registration 
> with errors such as
> {noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
> at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
> at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.maybeRegister(SecurityProviderRegistration.java:539)
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.activate(SecurityProviderRegistration.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> 

[jira] [Updated] (OAK-8529) Deregister MBeans on SecurityProviderRegistration component deactivation

[Robert Munteanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated OAK-8529:
-
Summary: Deregister MBeans on SecurityProviderRegistration component 
deactivation   (was: Eagerly deregister MBeans on SecurityProviderRegistration 
deactivation)

> Deregister MBeans on SecurityProviderRegistration component deactivation 
> -
>
> Key: OAK-8529
> URL: https://issues.apache.org/jira/browse/OAK-8529
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> The SecurityProviderRegistration is prone to being activated and deactivated 
> during a regular Sling application startup ( for a prolonged discussion see 
> SLING-7811 ). The instance should fully cleanup after itself to make sure it 
> will be usable after an activate/deactive cycle.
> In practice the MBeans remain registered and prevent a further registration 
> with errors such as
> {noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
> at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
> at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.maybeRegister(SecurityProviderRegistration.java:539)
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.activate(SecurityProviderRegistration.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> 

[jira] [Commented] (OAK-8529) Eagerly deregister MBeans on SecurityProviderRegistration deactivation

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929143#comment-16929143
 ] 

Robert Munteanu commented on OAK-8529:
--

[~angela] - I was actually wrong and this was not a race condition. The problem 
was that the {{deactivate}} method did not close the Closer, which meant that 
registered services would be dangling after a deactivate in case they did not 
go through the {{maybeUnregister()}} method. This is the case for instance with 
the {{AuthenticationConfiguration}} reference. I have updated the pull request 
with the change and with a failing test (that passes after my change).

Please see https://github.com/apache/jackrabbit-oak/pull/139/files .

Thanks!

> Eagerly deregister MBeans on SecurityProviderRegistration deactivation
> --
>
> Key: OAK-8529
> URL: https://issues.apache.org/jira/browse/OAK-8529
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> The SecurityProviderRegistration is prone to being activated and deactivated 
> during a regular Sling application startup ( for a prolonged discussion see 
> SLING-7811 ). The instance should fully cleanup after itself to make sure it 
> will be usable after an activate/deactive cycle.
> In practice the MBeans remain registered and prevent a further registration 
> with errors such as
> {noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
> at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
> at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.maybeRegister(SecurityProviderRegistration.java:539)
> at 
> 

[jira] [Resolved] (OAK-8622) Remove the version of the maven-resources-plugin from the fast profile

[Robert Munteanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved OAK-8622.
--
Resolution: Fixed

Fixed in https://svn.apache.org/r1866896

> Remove the version of the maven-resources-plugin from the fast profile
> --
>
> Key: OAK-8622
> URL: https://issues.apache.org/jira/browse/OAK-8622
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Trivial
> Fix For: 1.18.0
>
>
> The {{oak-parent}} pom contains a version for the {{maven-resources-plugin}} 
> in the _fast_ profile. This can lead to problems when executing that profile, 
> since the version of the plugin is otherwise inherited from the Maven parent 
> pom.
> For instance, with Maven 3.5.4 I get the following error when building Oak 
> with the _fast_ profile:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources 
> (default-resources) on project oak-it-osgi: Execution default-resources of 
> goal org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed: 
> An API incompatibility was encountered while executing 
> org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources: 
> java.lang.NoSuchMethodError: 'void 
> org.apache.maven.shared.filtering.MavenResourcesExecution.setAddDefaultExcludes(boolean)'
> [ERROR] -
> [ERROR] realm =
> plugin>org.apache.maven.plugins:maven-resources-plugin:3.1.0-1339233906
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = 
> file:/home/robert/.m2/repository/org/apache/maven/plugins/maven-resources-plugin/3.1.0/maven-resources-plugin-3.1.0.jar
> [ERROR] urls[1] = 
> file:/home/robert/.m2/repository/org/apache/maven/shared/maven-filtering/1.3/maven-filtering-1.3.jar
> [ERROR] urls[2] = 
> file:/home/robert/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[3] = 
> file:/home/robert/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> [ERROR] urls[4] = 
> file:/home/robert/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.6/maven-shared-utils-0.6.jar
> [ERROR] urls[5] = 
> file:/home/robert/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
> [ERROR] urls[6] = 
> file:/home/robert/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar
> [ERROR] urls[7] = 
> file:/home/robert/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> [ERROR] urls[8] = 
> file:/home/robert/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> [ERROR] urls[9] = 
> file:/home/robert/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> [ERROR] urls[10] = 
> file:/home/robert/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.jar
> [ERROR] urls[11] = 
> file:/home/robert/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[12] = 
> file:/home/robert/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[13] = 
> file:/home/robert/.m2/repository/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.jar
> [ERROR] urls[14] = 
> file:/home/robert/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar
> [ERROR] urls[15] = 
> file:/home/robert/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.24/plexus-interpolation-1.24.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
> {noformat}
> Removing the version fixes the problem for me.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (OAK-8622) Remove the version of the maven-resources-plugin from the fast profile

[Robert Munteanu (Jira)]

Robert Munteanu created OAK-8622:


 Summary: Remove the version of the maven-resources-plugin from the 
fast profile
 Key: OAK-8622
 URL: https://issues.apache.org/jira/browse/OAK-8622
 Project: Jackrabbit Oak
  Issue Type: Task
  Components: parent
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: 1.18.0


The {{oak-parent}} pom contains a version for the {{maven-resources-plugin}} in 
the _fast_ profile. This can lead to problems when executing that profile, 
since the version of the plugin is otherwise inherited from the Maven parent 
pom.

For instance, with Maven 3.5.4 I get the following error when building Oak with 
the _fast_ profile:

{noformat}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources 
(default-resources) on project oak-it-osgi: Execution default-resources of goal 
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed: An API 
incompatibility was encountered while executing 
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources: 
java.lang.NoSuchMethodError: 'void 
org.apache.maven.shared.filtering.MavenResourcesExecution.setAddDefaultExcludes(boolean)'
[ERROR] -
[ERROR] realm =
plugin>org.apache.maven.plugins:maven-resources-plugin:3.1.0-1339233906
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = 
file:/home/robert/.m2/repository/org/apache/maven/plugins/maven-resources-plugin/3.1.0/maven-resources-plugin-3.1.0.jar
[ERROR] urls[1] = 
file:/home/robert/.m2/repository/org/apache/maven/shared/maven-filtering/1.3/maven-filtering-1.3.jar
[ERROR] urls[2] = 
file:/home/robert/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[3] = 
file:/home/robert/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
[ERROR] urls[4] = 
file:/home/robert/.m2/repository/org/apache/maven/shared/maven-shared-utils/0.6/maven-shared-utils-0.6.jar
[ERROR] urls[5] = 
file:/home/robert/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
[ERROR] urls[6] = 
file:/home/robert/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar
[ERROR] urls[7] = 
file:/home/robert/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
[ERROR] urls[8] = 
file:/home/robert/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
[ERROR] urls[9] = 
file:/home/robert/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
[ERROR] urls[10] = 
file:/home/robert/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.jar
[ERROR] urls[11] = 
file:/home/robert/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[12] = 
file:/home/robert/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[13] = 
file:/home/robert/.m2/repository/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.jar
[ERROR] urls[14] = 
file:/home/robert/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar
[ERROR] urls[15] = 
file:/home/robert/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.24/plexus-interpolation-1.24.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
{noformat}

Removing the version fixes the problem for me.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (OAK-8529) Eagerly deregister MBeans on SecurityProviderRegistration deactivation

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929122#comment-16929122
 ] 

Robert Munteanu commented on OAK-8529:
--

[~angela] - I believe this to be a race condition, so providing a test will not 
be that easy. However, when reviewing my code I saw that the proposed change is 
incorrect, as it may close the closer too early. I'll try and come up with an 
updated patch.

> Eagerly deregister MBeans on SecurityProviderRegistration deactivation
> --
>
> Key: OAK-8529
> URL: https://issues.apache.org/jira/browse/OAK-8529
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> The SecurityProviderRegistration is prone to being activated and deactivated 
> during a regular Sling application startup ( for a prolonged discussion see 
> SLING-7811 ). The instance should fully cleanup after itself to make sure it 
> will be usable after an activate/deactive cycle.
> In practice the MBeans remain registered and prevent a further registration 
> with errors such as
> {noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
> at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
> at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.maybeRegister(SecurityProviderRegistration.java:539)
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.activate(SecurityProviderRegistration.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  

[jira] [Resolved] (OAK-8530) Ensure MBean are deregistered if the repository fails to start

[Robert Munteanu (Jira)]

 [ 
https://issues.apache.org/jira/browse/OAK-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved OAK-8530.
--
Resolution: Fixed

Fixed in https://svn.apache.org/r1866895.

> Ensure MBean are deregistered if the repository fails to start
> --
>
> Key: OAK-8530
> URL: https://issues.apache.org/jira/browse/OAK-8530
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> When used in OSGi environments the repository service is unfortunately prone 
> to restarts ( see SLING-7811 for the gory details ). Besides the performance 
> problem, the repository typically fails to restart since MBeans that were 
> registered once were not deregistered. The failures happen before repository 
> is constructed, so there is no instance to close.
> A typical stack trace is
> {noformat}
> 06.08.2019 09:55:03.894 *ERROR* [Apache Sling Repository Startup Thread #4] 
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean org.apache.jackrabbit.oak.management.RepositoryManager@5e05b159
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=repository manager,type=RepositoryManagement
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
>   at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
>   at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
>   at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>   at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>   at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
>   at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.Oak.createNewContentRepository(Oak.java:772) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:671) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.jcr.Jcr.createContentRepository(Jcr.java:376) 
> [org.apache.jackrabbit.oak-jcr:1.18.0.SNAPSHOT]
>   at 
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:152)
>  [org.apache.sling.jcr.oak.server:1.2.2]
>   at 
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
>  [org.apache.sling.jcr.base:3.0.6]
>   at 
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:86)
>  [org.apache.sling.jcr.base:3.0.6]
> 

[jira] [Commented] (OAK-8530) Ensure MBean are deregistered if the repository fails to start

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929069#comment-16929069
 ] 

Robert Munteanu commented on OAK-8530:
--

I guess there are no objections :) I'll rebase, retest and push the change.

> Ensure MBean are deregistered if the repository fails to start
> --
>
> Key: OAK-8530
> URL: https://issues.apache.org/jira/browse/OAK-8530
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> When used in OSGi environments the repository service is unfortunately prone 
> to restarts ( see SLING-7811 for the gory details ). Besides the performance 
> problem, the repository typically fails to restart since MBeans that were 
> registered once were not deregistered. The failures happen before repository 
> is constructed, so there is no instance to close.
> A typical stack trace is
> {noformat}
> 06.08.2019 09:55:03.894 *ERROR* [Apache Sling Repository Startup Thread #4] 
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean org.apache.jackrabbit.oak.management.RepositoryManager@5e05b159
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=repository manager,type=RepositoryManagement
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
>   at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
>   at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
>   at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>   at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>   at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
>   at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.Oak.createNewContentRepository(Oak.java:772) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:671) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.jcr.Jcr.createContentRepository(Jcr.java:376) 
> [org.apache.jackrabbit.oak-jcr:1.18.0.SNAPSHOT]
>   at 
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:152)
>  [org.apache.sling.jcr.oak.server:1.2.2]
>   at 
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
>  [org.apache.sling.jcr.base:3.0.6]
>   at 
> 

[jira] [Commented] (OAK-8325) Document Jenkins jobs

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16929031#comment-16929031
 ] 

Robert Munteanu commented on OAK-8325:
--

I've updated Jackrabbit-Oak-Windows to send notifications to 
oak-...@jackrabbit.apache.org, following [oak-...@jackrabbit.apache.org 
discussion|https://lists.apache.org/thread.html/9758a99781aecc5ceff04176abd5ae8e743cb0d3a797c5231bfdb8ce@%3Coak-dev.jackrabbit.apache.org%3E]
 .

> Document Jenkins jobs
> -
>
> Key: OAK-8325
> URL: https://issues.apache.org/jira/browse/OAK-8325
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: doc
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> h3.  "Jackrabbit Oak"
> <[https://builds.apache.org/job/Jackrabbit%20Oak/]>
>  - builds <[https://svn.apache.org/repos/asf/jackrabbit/oak/trunk]>
>  - builds with JDK 1.8 (latest)
>  - clean install -Ppedantic,integrationTesting -Dmongo.port=9 
> -Dcheckstyle.skip=true -Dfindbugs.skip=true -DtrimStackTrace=false
>  - sends notifications to oak-...@jackrabbit.apache.org
>  - appears stable
> h3. "Apache Jackrabbit Oak matrix"
> <[https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/]>
>  - builds <[https://svn.apache.org/repos/asf/jackrabbit/oak/trunk]>
>  - various targets (4 * 3 * 2 = 24):
>  ** by JDK 1.8 (latest), JDK 11 (latest), JDK 12 (latest), JDK 13 (latest)
>  ** DOCUMENT_RDB, DOCUMENT_NS, SEGMENT_TAR
>  ** unittesting and integrationTesting
>  - additional profiles: rat, guava-latest, javadoc, guavabetachecks
>  - no notifications
>  - not very stable, docker related failures
> h3. "Apache Jackrabbit Oak (maintenance branch) matrix"
> 
> Similar to the above, but builds all maintenance branches, but only for JDK 
> 7, 8, and 11.
> h3. "Jackrabbit-Oak-Windows"
> 
> Builds seem to be stable, notifications go to [~mduerig] apparently.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (OAK-8579) Composite Node Store: Allow creating an index in the read-only repo first

[Robert Munteanu (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917505#comment-16917505
 ] 

Robert Munteanu commented on OAK-8579:
--

[~tmueller] - sorry, I am too disconnected from these changes to feel confident 
that I can review them.

> Composite Node Store: Allow creating an index in the read-only repo first
> -
>
> Key: OAK-8579
> URL: https://issues.apache.org/jira/browse/OAK-8579
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite, core, indexing, lucene
>Reporter: Thomas Mueller
>Priority: Major
>
> Currently, it is not allowed to first create a new index in the read-only 
> repository, and then in the read-write repository. Trying to do so will fail 
> with "OakConstraint0001: /oak:index/.../:oak:mount-readOnlyV1-index-data[[]]: 
> The primary type null does not exist"
> See OAK-7917: oak-lucene/src/test/java/org/apache/jackrabbit/oak/composite - 
> CompositeNodeStoreLuceneIndexTest.java 
> tryAddIndexInReadWriteWithIndexExistinginReadOnly line 112. 
> It would be better to allow this use case, to reduce the possibility of 
> problems.
> We should specially test with lucene indexes, but also with property indexes. 
> (If that's more complicated, we can concentrate on the lucene case first.)



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (OAK-8529) Eagerly deregister MBeans on SecurityProviderRegistration deactivation

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900983#comment-16900983
 ] 

Robert Munteanu commented on OAK-8529:
--

[~angela], [~stillalex] - having a test case would be problematic. The way I 
see this is by starting up Apache Sling with a MongoDB setup which is 
pre-populated. It definitely has to do with the async nature of the Sling 
repository registration, which is not that easy to capture in a unit test.

I have tried to write a simple {{testReactivate}} test, but that did not 
trigger the problem

{code}diff --git 
a/oak-core/src/test/java/org/apache/jackrabbit/oak/security/internal/SecurityProviderRegistrationTest.java
 
b/oak-core/src/test/java/org/apache/jackrabbit/oak/security/internal/SecurityProviderRegistrationTest.java
index 95f24d22d8..6df41e744d 100644
--- 
a/oak-core/src/test/java/org/apache/jackrabbit/oak/security/internal/SecurityProviderRegistrationTest.java
+++ 
b/oak-core/src/test/java/org/apache/jackrabbit/oak/security/internal/SecurityProviderRegistrationTest.java
@@ -166,6 +166,38 @@ public class SecurityProviderRegistrationTest extends 
AbstractSecurityTest {
 assertNotNull(service);
 }
 
+@Test
+public void testReactivate() {
+registration.activate(context.bundleContext(), 
configWithRequiredServiceIds("serviceA", "serviceB"));
+
+SecurityProvider service = context.getService(SecurityProvider.class);
+assertNull(service);
+
+RestrictionProvider mockRp = mock(RestrictionProvider.class);
+ServiceReference sr = 
when(mock(ServiceReference.class).getProperty(SERVICE_PID)).thenReturn("serviceA").getMock();
+
+registration.bindRestrictionProvider(sr, mockRp);
+
+service = context.getService(SecurityProvider.class);
+assertNull(service);
+
+AuthorizationConfigurationImpl authzConfig = new 
AuthorizationConfigurationImpl();
+ImmutableMap autzProps = ImmutableMap.of(SERVICE_PID, 
"serviceB");
+
+registration.bindAuthorizationConfiguration(authzConfig, autzProps);
+service = context.getService(SecurityProvider.class);
+assertNotNull(service);
+
+registration.unbindAuthorizationConfiguration(authzConfig, autzProps);
+service = context.getService(SecurityProvider.class);
+assertNull(service);
+
+registration.bindAuthorizationConfiguration(authzConfig, autzProps);
+service = context.getService(SecurityProvider.class);
+assertNotNull(service);
+
+}
+
 @Test
 public void testActivate() {
 registration.activate(context.bundleContext(), 
configWithRequiredServiceIds("serviceA", "serviceB"));
{code}

> Eagerly deregister MBeans on SecurityProviderRegistration deactivation
> --
>
> Key: OAK-8529
> URL: https://issues.apache.org/jira/browse/OAK-8529
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> The SecurityProviderRegistration is prone to being activated and deactivated 
> during a regular Sling application startup ( for a prolonged discussion see 
> SLING-7811 ). The instance should fully cleanup after itself to make sure it 
> will be usable after an activate/deactive cycle.
> In practice the MBeans remain registered and prevent a further registration 
> with errors such as
> {noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at 
> 

[jira] [Commented] (OAK-8530) Ensure MBean are deregistered if the repository fails to start

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900942#comment-16900942
 ] 

Robert Munteanu commented on OAK-8530:
--

I submitted a PR with a fix at 
https://github.com/apache/jackrabbit-oak/pull/140. Not sure how to ask for a 
review, maybe [~mreutegg]?

> Ensure MBean are deregistered if the repository fails to start
> --
>
> Key: OAK-8530
> URL: https://issues.apache.org/jira/browse/OAK-8530
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> When used in OSGi environments the repository service is unfortunately prone 
> to restarts ( see SLING-7811 for the gory details ). Besides the performance 
> problem, the repository typically fails to restart since MBeans that were 
> registered once were not deregistered. The failures happen before repository 
> is constructed, so there is no instance to close.
> A typical stack trace is
> {noformat}
> 06.08.2019 09:55:03.894 *ERROR* [Apache Sling Repository Startup Thread #4] 
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean org.apache.jackrabbit.oak.management.RepositoryManager@5e05b159
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=repository manager,type=RepositoryManagement
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
>   at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
>   at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
>   at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>   at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>   at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
>   at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.Oak.createNewContentRepository(Oak.java:772) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:671) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.jcr.Jcr.createContentRepository(Jcr.java:376) 
> [org.apache.jackrabbit.oak-jcr:1.18.0.SNAPSHOT]
>   at 
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:152)
>  [org.apache.sling.jcr.oak.server:1.2.2]
>   at 
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
>  [org.apache.sling.jcr.base:3.0.6]
>   at 
> 

[jira] [Created] (OAK-8530) Ensure MBean are deregister if the repository fails to start

[Robert Munteanu (JIRA)]

Robert Munteanu created OAK-8530:


 Summary: Ensure MBean are deregister if the repository fails to 
start
 Key: OAK-8530
 URL: https://issues.apache.org/jira/browse/OAK-8530
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: core
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: 1.18.0


When used in OSGi environments the repository service is unfortunately prone to 
restarts ( see SLING-7811 for the gory details ). Besides the performance 
problem, the repository typically fails to restart since MBeans that were 
registered once were not deregistered. The failures happen before repository is 
constructed, so there is no instance to close.

A typical stack trace is

{noformat}
06.08.2019 09:55:03.894 *ERROR* [Apache Sling Repository Startup Thread #4] 
org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering MBean 
org.apache.jackrabbit.oak.management.RepositoryManager@5e05b159
javax.management.InstanceAlreadyExistsException: 
org.apache.jackrabbit.oak:name=repository manager,type=RepositoryManagement
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at 
org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
at 
org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
at 
org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
at 
org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
at 
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
at 
org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
at 
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
at 
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
at 
org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
at 
org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
 [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
at 
org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
 [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
at 
org.apache.jackrabbit.oak.Oak.createNewContentRepository(Oak.java:772) 
[org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:671) 
[org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
at 
org.apache.jackrabbit.oak.jcr.Jcr.createContentRepository(Jcr.java:376) 
[org.apache.jackrabbit.oak-jcr:1.18.0.SNAPSHOT]
at 
org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:152)
 [org.apache.sling.jcr.oak.server:1.2.2]
at 
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
 [org.apache.sling.jcr.base:3.0.6]
at 
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:86)
 [org.apache.sling.jcr.base:3.0.6]
{noformat}

I will propose a patch shortly.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (OAK-8530) Ensure MBean are deregistered if the repository fails to start

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated OAK-8530:
-
Summary: Ensure MBean are deregistered if the repository fails to start  
(was: Ensure MBean are deregister if the repository fails to start)

> Ensure MBean are deregistered if the repository fails to start
> --
>
> Key: OAK-8530
> URL: https://issues.apache.org/jira/browse/OAK-8530
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> When used in OSGi environments the repository service is unfortunately prone 
> to restarts ( see SLING-7811 for the gory details ). Besides the performance 
> problem, the repository typically fails to restart since MBeans that were 
> registered once were not deregistered. The failures happen before repository 
> is constructed, so there is no instance to close.
> A typical stack trace is
> {noformat}
> 06.08.2019 09:55:03.894 *ERROR* [Apache Sling Repository Startup Thread #4] 
> org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean org.apache.jackrabbit.oak.management.RepositoryManager@5e05b159
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=repository manager,type=RepositoryManagement
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>   at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
>   at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
>   at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
>   at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
>   at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
>   at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
>   at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
>   at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
>   at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
>   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
>   at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
>   at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
>   at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.Oak.createNewContentRepository(Oak.java:772) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at org.apache.jackrabbit.oak.Oak.createContentRepository(Oak.java:671) 
> [org.apache.jackrabbit.oak-core:1.18.0.SNAPSHOT]
>   at 
> org.apache.jackrabbit.oak.jcr.Jcr.createContentRepository(Jcr.java:376) 
> [org.apache.jackrabbit.oak-jcr:1.18.0.SNAPSHOT]
>   at 
> org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:152)
>  [org.apache.sling.jcr.oak.server:1.2.2]
>   at 
> org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
>  [org.apache.sling.jcr.base:3.0.6]
>   at 
> 

[jira] [Commented] (OAK-8529) Eagerly deregister MBeans on SecurityProviderRegistration deactivation

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900932#comment-16900932
 ] 

Robert Munteanu commented on OAK-8529:
--

[~angela] - can you please take a look at the PR from 
https://github.com/apache/jackrabbit-oak/pull/139?

> Eagerly deregister MBeans on SecurityProviderRegistration deactivation
> --
>
> Key: OAK-8529
> URL: https://issues.apache.org/jira/browse/OAK-8529
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: 1.18.0
>
>
> The SecurityProviderRegistration is prone to being activated and deactivated 
> during a regular Sling application startup ( for a prolonged discussion see 
> SLING-7811 ). The instance should fully cleanup after itself to make sure it 
> will be usable after an activate/deactive cycle.
> In practice the MBeans remain registered and prevent a further registration 
> with errors such as
> {noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
> ConfigurationEvent: 
> pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
>  org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
> MBean 
> org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
> javax.management.InstanceAlreadyExistsException: 
> org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
> at 
> org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
> at 
> org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at 
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at 
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at 
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
> at 
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at 
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
> at 
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
>  [org.apache.jackrabbit.oak-core-spi:1.16.0]
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.maybeRegister(SecurityProviderRegistration.java:539)
> at 
> org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.activate(SecurityProviderRegistration.java:191)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> 

[jira] [Created] (OAK-8529) Eagerly deregister MBeans on SecurityProviderRegistration deactivation

[Robert Munteanu (JIRA)]

Robert Munteanu created OAK-8529:


 Summary: Eagerly deregister MBeans on SecurityProviderRegistration 
deactivation
 Key: OAK-8529
 URL: https://issues.apache.org/jira/browse/OAK-8529
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: security
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: 1.18.0


The SecurityProviderRegistration is prone to being activated and deactivated 
during a regular Sling application startup ( for a prolonged discussion see 
SLING-7811 ). The instance should fully cleanup after itself to make sure it 
will be usable after an activate/deactive cycle.

In practice the MBeans remain registered and prevent a further registration 
with errors such as

{noformat}6.08.2019 09:43:51.051 *ERROR* [CM Event Dispatcher (Fire 
ConfigurationEvent: 
pid=org.apache.jackrabbit.oak.security.authentication.AuthenticationConfigurationImpl)]
 org.apache.aries.jmx.whiteboard.MBeanHolder register: Failure registering 
MBean org.apache.aries.jmx.util.shared.RegistrableStandardEmitterMBean@45011485 
javax.management.InstanceAlreadyExistsException: 
org.apache.jackrabbit.oak:name=LoginModule statistics,type=LoginModuleStats
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at 
org.apache.aries.jmx.whiteboard.MBeanHolder.register(MBeanHolder.java:114)
at 
org.apache.aries.jmx.whiteboard.JmxWhiteboardSupport.registerMBean(JmxWhiteboardSupport.java:88)
at 
org.apache.aries.jmx.whiteboard.Activator$MBeanTracker.addingService(Activator.java:102)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
at 
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at 
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
at 
org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
at 
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
at 
org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4833)
at org.apache.felix.framework.Felix.registerService(Felix.java:3804)
at 
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
at 
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:302)
at 
org.apache.jackrabbit.oak.osgi.OsgiWhiteboard.register(OsgiWhiteboard.java:79)
at 
org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:115)
 [org.apache.jackrabbit.oak-core-spi:1.16.0]
at 
org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardUtils.registerMBean(WhiteboardUtils.java:99)
 [org.apache.jackrabbit.oak-core-spi:1.16.0]
at 
org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.maybeRegister(SecurityProviderRegistration.java:539)
at 
org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration.activate(SecurityProviderRegistration.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228)
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41)
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664)
at 
org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510)
at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317)
at 
org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307)
at 

[jira] [Commented] (OAK-7217) check public Oak APIs for references to Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16842184#comment-16842184
 ] 

Robert Munteanu commented on OAK-7217:
--

That change is unfortunately neither source nor binary compatible. So we can 
not perform it without breaking backwards compatibility. 

The explanation of the binary compatiblitiy that I found is somewhere under 
https://docs.oracle.com/javase/specs/jls/se12/html/jls-13.html, where it says 
that 

{quote}The signature of a method must include all of the following as 
determined by §15.12.3:
* The simple name of the method
* The number of parameters to the method
* A symbolic reference to the type of each parameter
{quote}

If the types change, the method signature changes. If the signature changes, 
then it can no longer link. If it no longer links, it's no longer binary 
compatible.

> check public Oak APIs for references to Guava
> -
>
> Key: OAK-7217
> URL: https://issues.apache.org/jira/browse/OAK-7217
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: detect-api.diff, extract-guava.sh, 
> fileutils-no-commons.diff, guava-global.log, guava-public-v2.log, 
> guava-public.log
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812748#comment-16812748
 ] 

Robert Munteanu commented on OAK-6880:
--

Oh, missed that, sorry [~reschke].

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu reopened OAK-6880:
--

Reopening as we have additional information and would like to pursue other 
solutions.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812571#comment-16812571
 ] 

Robert Munteanu commented on OAK-6880:
--

... ( I seem to be live-streaming this, sorry ).

I discovered that when trying to access the solr-parent artifact from the 
Artifactory UI, the pom.xml is passed through unchanged from Central. 
_However_, when accessing through the virtual repository that I have configured 
for development the pom is rewritten.

Therefore I think that the solution to add the repository reference to Oak is 
the wrong one and suggest to roll back that change. Instead, we should make 
sure that we use the right solr parent pom.

Thoughts [~edivad]?

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812569#comment-16812569
 ] 

Robert Munteanu commented on OAK-6880:
--

It seems that we would be able to exclude unexpected Maven artifacts using a 
custom enforcer rule, see

https://stackoverflow.com/questions/14214406/how-to-enforce-a-strict-maven-dependency-policy-dependency-chain-attack

So we could revert the change and validate that the artifact is strictly the 
upstream one. This would make the builds reproducible and clearly state the 
reason for failure.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812566#comment-16812566
 ] 

Robert Munteanu commented on OAK-6880:
--

... however, there is reason to believe Artifactory is involved. In the [JFrog 
virtual repositories 
documentation|https://www.jfrog.com/confluence/display/RTF/Virtual+Repositories#VirtualRepositories-Maven,Gradle,IvyandSBTRepositories]
 it is documented that Maven repositories can configured to remove all 
{{}} elements.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812561#comment-16812561
 ] 

Robert Munteanu commented on OAK-6880:
--

{code}$ grep -ce repository solr-parent-5.5.5.pom
0
$ cat solr-parent-5.5.5.pom.sha1 
aa3b35c3527c2a846d40f4c292d82e8a3ae0d5b7
{code}

Using that SHA1 for a Maven central returns 0 hits: 
https://search.maven.org/search?q=1:aa3b35c3527c2a846d40f4c292d82e8a3ae0d5b7 . 
Searching for another artifact by SHA works, so the search is correct: 
https://search.maven.org/search?q=1:bba42037edb3c62f62900812e62b66eca2c61d4b .

I have the 'broken' artifact locally as well but not sure where it's coming 
from. I checked the Adobe artifactory instance but only found the 'vanilla' 
solr-parent-5.5.5.pom, cached from Maven central.

BTW, this is precisely why I dislike managing {{}} elements in the 
project pom.xml .

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Reporter: Christian Schneider
>Assignee: Julian Reschke
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772964#comment-16772964
 ] 

Robert Munteanu commented on OAK-7182:
--

That is an option indeed [~edivad]. I view it somehow as the "nuclear" option, 
as it is a big departure from "traditional" dependency management. And, in 
practice, we will only need this for Guava, right?

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772838#comment-16772838
 ] 

Robert Munteanu commented on OAK-7182:
--

{quote}Not that I disagree, but could you clarify why it's a problem for 
non-exported APIs?{quote}

I consider it a problem because we have seem multiple times that Guava APIs 
change in backwards incompatible ways. The smaller the exposure we have to 
Guava APIs, the easier it is for us to support multiple Guava versions.

{quote}Shading is a problem because of the size, unless we create a separate 
Oak module which does nothing except shading all of Guava.{quote}

I would hope that we don't need all of Guava. But yes, size is an issue, 
together with the issue of customers depending on updating Oak to get newer 
Guava versions - but I guess this is the current situation anyway.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771136#comment-16771136
 ] 

Robert Munteanu commented on OAK-7182:
--

[~stillalex] - I eventually managed to take a look at your diff. The fact that 
you had to basically replicate the Guava API in a compat layer is indeed a bad 
smell.

I would suggest that - if needed - we simply do away with the Guava APIs and 
implement our own, e.g. instead of having 
{{org.apache.jackrabbit.oak.commons.guava.MoreExecutorsCompat}} we have a 
{{org.apache.jackrabbit.oak.commons.concurrent.OakExecutors}} where we supply 
whatever is needed by Oak under our own APIs. I have come to strongly believe 
that any leak of Guava APIs in the Oak codebase - whether it's in exported API 
or not - is a risk. Therefore I would favour only accessing it from a limited 
amount of classes so migration to newer version (or even away from Guava) is 
possible.

I think that the only way this can eventually work is to no longer import Guava 
at runtime, either by replacing it completely or by importing it statically and 
shading it (optional rant below).



For more context, I believe that it's important that we understand where Guava 
is coming from. Google famously stores all it's code in a monorepo ( 
https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
 ). Not only is all the code stored in a single repository - including shared 
libraries like Guava and external dependencies like JUnit, but also all 
dependencies are upgraded _at the same time_. This means that all projects in 
trunk depend on a single version of Guava at a single point in time.

For this kind of setup the way Guava does versioning and backwards 
compatibility is perfectly fine - you give everyone time to adapt to new 
releases and then stop supporting the old code. However, it is fundamentally at 
odds with being used in projects with a large number of dependencies, each one 
having its own Guava version. This is precisely why we must minimise our 
exposure to Guava and keep it behind adapter classes or even remove it outright.

The sooner we do this the better.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: GuavaTests.java, OAK-7182-guava-21-3.diff, 
> OAK-7182-guava-21-4.diff, OAK-7182-guava-21.diff, OAK-7182-guava-23.6.1.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7906) StackOverFlowError SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711255#comment-16711255
 ] 

Robert Munteanu commented on OAK-7906:
--

Ah ok, I did not know that.

> StackOverFlowError 
> SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12
> -
>
> Key: OAK-7906
> URL: https://issues.apache.org/jira/browse/OAK-7906
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.9.11
>Reporter: Julian Reschke
>Priority: Major
>  Labels: Java12
>
> Happens with version 20 (2018/11/15).
> It appears that the StackOverflowError happens when obtaining many sessions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7906) StackOverFlowError SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16711211#comment-16711211
 ] 

Robert Munteanu commented on OAK-7906:
--

Then it looks like a JDK bug, right? Might be worth reporting.

> StackOverFlowError 
> SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12
> -
>
> Key: OAK-7906
> URL: https://issues.apache.org/jira/browse/OAK-7906
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.9.11
>Reporter: Julian Reschke
>Priority: Major
>  Labels: Java12
>
> Happens with version 20 (2018/11/15).
> It appears that the StackOverflowError happens when obtaining many sessions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7910) Composite node store: Creating a new Lucene index; reindex

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694969#comment-16694969
 ] 

Robert Munteanu commented on OAK-7910:
--

[~tmueller] - does the index being created include paths from the read-only 
mount? I would think that it's best to not create and nodes in the read-only 
mount if not absolutely necessary.

> Composite node store: Creating a new Lucene index; reindex
> --
>
> Key: OAK-7910
> URL: https://issues.apache.org/jira/browse/OAK-7910
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite, core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> With the composite node store, creating a Lucene index in the read-write 
> repository fails due to the exception below. I think Oak shouldn't try to do 
> node type validation for hidden nodes.
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeAdded(CompositeNodeState.java:304)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeAdded(CompositeNodeState.java:247)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeAdded(CompositeNodeState.java:304)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeAdded(CompositeNodeState.java:247)
>  

[jira] [Commented] (OAK-7906) StackOverFlowError SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694961#comment-16694961
 ] 

Robert Munteanu commented on OAK-7906:
--

Another data point:

{noformat}[INFO] 

[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  33:43 min
[INFO] Finished at: 2018-11-21T16:31:51+01:00
[INFO] 
robert@rombert:~/Documents/sources/apache/jackrabbit-oak (trunk)> mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T20:41:47+02:00)
Maven home: /usr/share/java/maven
Java version: 12-ea, vendor: Oracle Corporation, runtime: /opt/jdk-12
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.19.2-1-default", arch: "amd64", family: "unix"
robert@rombert:~/Documents/sources/apache/jackrabbit-oak (trunk)> java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+20)
OpenJDK 64-Bit Server VM (build 12-ea+20, mixed mode, sharing)
{noformat}

> StackOverFlowError 
> SessionStatsTest.testInitStackTraceEnabledAfterOpeningManySessions with jdk-12
> -
>
> Key: OAK-7906
> URL: https://issues.apache.org/jira/browse/OAK-7906
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Affects Versions: 1.9.11
>Reporter: Julian Reschke
>Priority: Major
>  Labels: Java12
>
> Happens with version 20 (2018/11/15).
> It appears that the StackOverflowError happens when obtaining many sessions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7910) Composite node store: Creating a new Lucene index; reindex

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694660#comment-16694660
 ] 

Robert Munteanu commented on OAK-7910:
--

[~tmueller] - a separate test would be best I think. I am not aware of any 
tests running via the JCR APIs, unless these are exercised via the parametrized 
tests, see {{CompositeStoreFixture}}.

> Composite node store: Creating a new Lucene index; reindex
> --
>
> Key: OAK-7910
> URL: https://issues.apache.org/jira/browse/OAK-7910
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite, core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> With the composite node store, creating a Lucene index in the read-write 
> repository fails due to the exception below. I think Oak shouldn't try to do 
> node type validation for hidden nodes.
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeAdded(CompositeNodeState.java:304)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeAdded(CompositeNodeState.java:247)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeAdded(CompositeNodeState.java:304)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeAdded(CompositeNodeState.java:247)
>  

[jira] [Commented] (OAK-7910) Composite node store: Creating a new Lucene index; reindex

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693203#comment-16693203
 ] 

Robert Munteanu commented on OAK-7910:
--

[~tmueller] - I am only aware of

* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-it/src/test/java/org/apache/jackrabbit/oak/composite/CompositeNodeStoreTest.java
* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/plugins/index/property/MultiplexersTest.java
* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/writer/MultiplexersLuceneTest.java

and I don't think any of the covers your scenario.

> Composite node store: Creating a new Lucene index; reindex
> --
>
> Key: OAK-7910
> URL: https://issues.apache.org/jira/browse/OAK-7910
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite, core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> With the composite node store, creating a Lucene index in the read-write 
> repository fails due to the exception below. I think Oak shouldn't try to do 
> node type validation for hidden nodes.
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeAdded(CompositeNodeState.java:304)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeAdded(CompositeNodeState.java:247)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> 

[jira] [Comment Edited] (OAK-7910) Composite node store: Creating a new Lucene index; reindex

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693203#comment-16693203
 ] 

Robert Munteanu edited comment on OAK-7910 at 11/20/18 1:04 PM:


[~tmueller] - I am only aware of

* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-it/src/test/java/org/apache/jackrabbit/oak/composite/CompositeNodeStoreTest.java
* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/plugins/index/property/MultiplexersTest.java
* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/writer/MultiplexersLuceneTest.java

and I don't think any of them covers your scenario.


was (Author: rombert):
[~tmueller] - I am only aware of

* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-it/src/test/java/org/apache/jackrabbit/oak/composite/CompositeNodeStoreTest.java
* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/test/java/org/apache/jackrabbit/oak/plugins/index/property/MultiplexersTest.java
* 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index/lucene/writer/MultiplexersLuceneTest.java

and I don't think any of the covers your scenario.

> Composite node store: Creating a new Lucene index; reindex
> --
>
> Key: OAK-7910
> URL: https://issues.apache.org/jira/browse/OAK-7910
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite, core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
>
> With the composite node store, creating a Lucene index in the read-write 
> repository fails due to the exception below. I think Oak shouldn't try to do 
> node type validation for hidden nodes.
> {noformat}
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.enter(TypeEditor.java:276)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:53)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:65)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.childNodeAdded(EditorDiff.java:121)
>  [org.apache.jackrabbit.oak-store-spi:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$WrappingDiff.childNodeAdded(CompositeNodeState.java:304)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.composite.CompositeNodeState$ChildrenDiffFilter.childNodeAdded(CompositeNodeState.java:247)
>  [org.apache.jackrabbit.oak-store-composite:1.9.10.R1845889]
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: 
> OakConstraint0001: /oak:index/test/:oak:mount-libs-index-data[[]]: The 
> primary type null does not exist
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor$1.onConstraintViolation(TypeEditor.java:109)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.constraintViolation(TypeEditor.java:234)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.createEffectiveType(TypeEditor.java:337)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.(TypeEditor.java:203)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> org.apache.jackrabbit.oak.plugins.nodetype.TypeEditor.checkNodeTypeConstraints(TypeEditor.java:482)
>  [org.apache.jackrabbit.oak-core:1.9.10.R1845889]
>   at 
> 

[jira] [Commented] (OAK-7817) oak-doc-railroad-macro should be built in default reactor built

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672785#comment-16672785
 ] 

Robert Munteanu commented on OAK-7817:
--

For creating native Git repositories there are two options at Apache:

* Gitbox, which sets up a dual-master setup between the ASF git repositories 
and the GitHub ones - https://gitbox.apache.org/
* Git-Wip, which sets up independent git repositories which are then mirrored 
over to GitHub - https://git-wip-us.apache.org/

In Slng we went with Gitbox to get the benefit of merging pull requests via 
Github.

Gitbox is fully self-serve and you can create the repositories from the the 
page I linked above. Infra intervention might be required if you need to make 
some particular changes to the existing SVN tree, for instance to make the old 
SVN location read-only. But creating gitbox repositories does not require INFRA 
intervention.

> oak-doc-railroad-macro should be built in default reactor built
> ---
>
> Key: OAK-7817
> URL: https://issues.apache.org/jira/browse/OAK-7817
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> {{oak-doc}} is dependent on {{oak-doc-railroad-macro}} but the site 
> generation step mentioned in {{oak-doc/README}} have {{mvn site -Pdoc}} which 
> wont' build railroad macro module.
> So, on a fresh system (or cleaned .m2 folder) would fail to do {{mvn site 
> -Pdoc}}.
> A simple solution (outside of mentioning this in README itself) is to build 
> {{oak-doc-railroad-macro}} in default reactor build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6166) Support versioning in the composite node store

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu updated OAK-6166:
-
Summary: Support versioning in the composite node store  (was: Support 
versioning in the federated node store)

> Support versioning in the composite node store
> --
>
> Key: OAK-6166
> URL: https://issues.apache.org/jira/browse/OAK-6166
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.10, 1.9.11
>
>
> The mount info provider should affect the versioning code as well, so version 
> histories for the mounted paths are stored separately. Similarly to what we 
> have in the indexing, let's store the mounted version histories under:
> /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663486#comment-16663486
 ] 

Robert Munteanu commented on OAK-6880:
--

https://issues.apache.org/jira/browse/OAK-6880?focusedCommentId=16281703=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16281703

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Affects Versions: 1.8.0
>Reporter: Christian Schneider
>Assignee: Davide Giannella
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663443#comment-16663443
 ] 

Robert Munteanu commented on OAK-6880:
--

Restlet are tracking this with 
https://github.com/restlet/restlet-framework-java/issues/481 , I added a 
comment/offer for help. Let's see, maybe something comes out of it.

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Affects Versions: 1.8.0
>Reporter: Christian Schneider
>Assignee: Davide Giannella
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663436#comment-16663436
 ] 

Robert Munteanu commented on OAK-6880:
--

I believe we should not ask users to have a custom {{settings.xml}} file for 
Oak. The project should "just build" based on the Maven central repo.

Regarding adding a {{repository}} element as suggested in OAK-7811, it's 
discouraged - see first item under 
https://maven.apache.org/repository/guide-central-repository-upload.html#FAQ_and_common_mistakes
 .

I am not sure what the best way out is. For the sake of being complete, here's 
all the possible ideas that I can think of:

*  get the Restlet Jars on Maven cetral ( see also 
https://restlet.com/open-source/documentation/user-guide/2.3/introduction/getting-started/maven
 ). However, they went through the trouble to set up their own Maven repo so 
there must be a reason for not going to Maven Central
* remove the restlet dependency, but IIRC [~teofili] says that it's a hard 
requirement for the Solr server
* deploy our own renamed restlet jars, e.g. {{o.a.j.o.external.restlet-blah}} 
to Nexus and replace all "original" restlet dependencies with the repackaged 
ones. But sounds like a lot of effort we need to redo for every solr version 
upgrade
* add a {{repository}} element to the POM. Besides the problems listed in the 
Maven FAQ, we will slow down builds as each artifact will be potentially looked 
up in the restlet repository as well and we risk introducing instability in the 
builds.
* document the need to add a custom settings.xml file

Needless to say, there's none that is immediately applicable and "correct".

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Affects Versions: 1.8.0
>Reporter: Christian Schneider
>Assignee: Davide Giannella
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7851) Inline or remove embedding of Netty jars

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655106#comment-16655106
 ] 

Robert Munteanu commented on OAK-7851:
--

[~frm], [~mduerig] - FYI

> Inline or remove embedding of Netty jars
> 
>
> Key: OAK-7851
> URL: https://issues.apache.org/jira/browse/OAK-7851
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Robert Munteanu
>Priority: Major
>
> The {{oak-segment}} jar embeds a number of jars, mostly from Netty: 
> {noformat}concurrentlinkedhashmap-lru-1.4.2.jar
> netty-buffer-4.1.14.Final.jar
> netty-codec-4.1.14.Final.jar
> netty-common-4.1.14.Final.jar
> netty-handler-4.1.14.Final.jar
> netty-resolver-4.1.14.Final.jar
> netty-transport-4.1.14.Final.jar{noformat}
> This causes a small performance hit on startup and the jars must be always 
> expanded. This is more visible when using the Sling feature launcher as it 
> uses references to existing jar files instead of copying them around.
> There is also a space impact, as the embedded jars will be stored both in the 
> segment-tar jar _and_ on disk after being copied out.
> Additionally, the visibility of these jar can be controlled with the API 
> regions mechanism, to make it clear that they are not mean to be consumed 
> outside Oak, so it should be safe to remove the embedding altogether. 
> Alternatively, these can be still embedded but also inlined.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7851) Inline or remove embedding of Netty jars

[Robert Munteanu (JIRA)]

Robert Munteanu created OAK-7851:


 Summary: Inline or remove embedding of Netty jars
 Key: OAK-7851
 URL: https://issues.apache.org/jira/browse/OAK-7851
 Project: Jackrabbit Oak
  Issue Type: Improvement
  Components: segment-tar
Reporter: Robert Munteanu


The {{oak-segment}} jar embeds a number of jars, mostly from Netty: 

{noformat}concurrentlinkedhashmap-lru-1.4.2.jar
netty-buffer-4.1.14.Final.jar
netty-codec-4.1.14.Final.jar
netty-common-4.1.14.Final.jar
netty-handler-4.1.14.Final.jar
netty-resolver-4.1.14.Final.jar
netty-transport-4.1.14.Final.jar{noformat}

This causes a small performance hit on startup and the jars must be always 
expanded. This is more visible when using the Sling feature launcher as it uses 
references to existing jar files instead of copying them around.

There is also a space impact, as the embedded jars will be stored both in the 
segment-tar jar _and_ on disk after being copied out.

Additionally, the visibility of these jar can be controlled with the API 
regions mechanism, to make it clear that they are not mean to be consumed 
outside Oak, so it should be safe to remove the embedding altogether. 
Alternatively, these can be still embedded but also inlined.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7776) Ignore copying of :clusterConfig in InitialContentMigrator

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625925#comment-16625925
 ] 

Robert Munteanu commented on OAK-7776:
--

Conceptually looks good to me, but since it's Tomek's work I think he's the one 
that would know best.

> Ignore copying of :clusterConfig in InitialContentMigrator
> --
>
> Key: OAK-7776
> URL: https://issues.apache.org/jira/browse/OAK-7776
> Project: Jackrabbit Oak
>  Issue Type: Bug
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.10, 1.9.9
>
>
> :clusterConfig entry which stores the latest clusterId/repositoryId used for 
> registering the repository in the DataStore gets wiped out for the global 
> store if content is migrated by InitialContentMigrator. The consequence of 
> this is that there are multiple repositoryId created at unexpected times and 
> also files corresponding to them created in the DataStore which would block 
> DSGC.
> This should be excluded when copying to the target store as that store would 
> be the main/writable one. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7746) Refactor TypePredicate location and usage

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617241#comment-16617241
 ] 

Robert Munteanu commented on OAK-7746:
--

[~stillalex] - that's a nice chunk of changes :-)

The only point where things are not clear-cut is the one you mentioned - 
supporting both {{Predicate}} classes. For instance in 
UuidPredicate/PropertyPredicate/UniversalFilter we have a number of options:

- support just the JDK {{Predicate}}
- support both {{Predicate}}s
- split classes so that each support only one {{Predicate}}

>From a backwards compatibility POV I think the most expensive could be 
>supporting both, since there might come a point where we stop using the Guava 
>{{Predicate}} and then we actually have to remove methods which leads to a 
>bigger BC problem.  It just might be safer to only support the JDK 
>{{Predicate}}

> Refactor TypePredicate location and usage
> -
>
> Key: OAK-7746
> URL: https://issues.apache.org/jira/browse/OAK-7746
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, store-spi
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
>  Labels: modularization
>
> In the context of modularization I would like to move the TypePredicate class 
> to a dedicated package in store-spi (due to dependency on NodeState class). 
> See [0] for some more reasoning.
> Proposed patch [1].
> I'm concerned about the Predicate (guava) and Predicate (jdk) usage. I think 
> in a later guava release they will have Predicate extend the jdk version and 
> advise people to start using the latter, so I think the patch is taking a 
> step in a good direction, but would like to confirm this with others.
> Re. backwards compatibility, even if some packages are not exported (like 
> observation) I did my best to deprecate and add newer alternatives. If this 
> is not needed I can just drop the old methods.
> [0] 
> https://issues.apache.org/jira/browse/OAK-7499?focusedCommentId=16486800=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16486800
> [1] 
> https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:type-predicate



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7758) Non-blocking CompositeNodeStore merges

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16617216#comment-16617216
 ] 

Robert Munteanu commented on OAK-7758:
--

The lock was introduced with OAK-6455, so it's definitely needed. We could 
discuss improvements to it though, see  
https://issues.apache.org/jira/browse/OAK-6455?focusedCommentId=16096696=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16096696

> Non-blocking CompositeNodeStore merges
> --
>
> Key: OAK-7758
> URL: https://issues.apache.org/jira/browse/OAK-7758
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Marcel Reutegger
>Priority: Major
> Fix For: 1.10
>
>
> The CompositeNodeStore serializes all merges with a lock. This prevents 
> concurrent processing of merges by the DocumentNodeStore.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6880) Build fails on a fresh m2 repo

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610540#comment-16610540
 ] 

Robert Munteanu commented on OAK-6880:
--

[~edivad] - see also my comment at 
https://issues.apache.org/jira/browse/OAK-6880?focusedCommentId=16281573=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16281573

> Build fails on a fresh m2 repo
> --
>
> Key: OAK-6880
> URL: https://issues.apache.org/jira/browse/OAK-6880
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: parent
>Affects Versions: 1.8.0
>Reporter: Christian Schneider
>Assignee: Davide Giannella
>Priority: Major
>
> When I build from a fresh m2 repo with no special settings.xml I get this 
> failure:
> {noformat}
> [ERROR] Failed to execute goal on project oak-solr-core: Could not resolve 
> dependencies for project 
> org.apache.jackrabbit:oak-solr-core:bundle:1.8-SNAPSHOT: The following 
> artifacts could not be resolved: org.restlet.jee:org.restlet:jar:2.1.1, 
> org.restlet.jee:org.restlet.ext.servlet:jar:2.1.1: Failure to find 
> org.restlet.jee:org.restlet:jar:2.1.1 in https://repo.maven.apache.org/maven2 
> was cached in the local repository, resolution will not be reattempted until 
> the update interval of central has elapsed or updates are forced -> [Help 1]
> {noformat}
> It seems the restlet jars are only in the restlet maven repo.
> I will provide a PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7710) CompositeNodeStore does not dispatch external events to observers

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597597#comment-16597597
 ] 

Robert Munteanu commented on OAK-7710:
--

[~tomek.rekawek] - I have limited time for the next two weeks, so if you can 
tackle it please do. 

> CompositeNodeStore does not dispatch external events to observers
> -
>
> Key: OAK-7710
> URL: https://issues.apache.org/jira/browse/OAK-7710
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: composite
>Reporter: Vikas Saurabh
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7710.patch, OAK-7710.test.patch
>
>
> Currently {{CompositeNodeStore}} only ever dispatches changes from inside its 
> {{merge}} method. This then loses external events that could be read in 
> background read of some underlying {{DocumentNodeStore}}.
> [^OAK-7710.test.patch] has an ignored test representing the scenario.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7710) CompositeNodeStore does not dispatch external events to observers

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587356#comment-16587356
 ] 

Robert Munteanu commented on OAK-7710:
--

Sounds good to me.

> CompositeNodeStore does not dispatch external events to observers
> -
>
> Key: OAK-7710
> URL: https://issues.apache.org/jira/browse/OAK-7710
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: composite
>Reporter: Vikas Saurabh
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7710.test.patch
>
>
> Currently {{CompositeNodeStore}} only ever dispatches changes from inside its 
> {{merge}} method. This then loses external events that could be read in 
> background read of some underlying {{DocumentNodeStore}}.
> [^OAK-7710.test.patch] has an ignored test representing the scenario.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7710) CompositeNodeStore does not dispatch external events to observers

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587315#comment-16587315
 ] 

Robert Munteanu commented on OAK-7710:
--

{quote}the current scheme might be useful when a single commit might span 
multiple underlying writable stores.{quote}

At the moment writes are disabled by setup for the {{CompositeNodeStore}}. Yes, 
the capability exists but for multiple reasons we don't support it. So I think 
we should support event dispatch to minimise the differences between composite 
and non-composite setups.

> CompositeNodeStore does not dispatch external events to observers
> -
>
> Key: OAK-7710
> URL: https://issues.apache.org/jira/browse/OAK-7710
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: composite
>Reporter: Vikas Saurabh
>Priority: Major
> Fix For: 1.10
>
> Attachments: OAK-7710.test.patch
>
>
> Currently {{CompositeNodeStore}} only ever dispatches changes from inside its 
> {{merge}} method. This then loses external events that could be read in 
> background read of some underlying {{DocumentNodeStore}}.
> [^OAK-7710.test.patch] has an ignored test representing the scenario.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7645) Update to MongoDB Java driver 3.8

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549208#comment-16549208
 ] 

Robert Munteanu commented on OAK-7645:
--

Ah, true, testcontainers would not work as a mock.

> Update to MongoDB Java driver 3.8
> -
>
> Key: OAK-7645
> URL: https://issues.apache.org/jira/browse/OAK-7645
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.10
>
>
> The updated driver adds compatibility with MongoDB 4.0 and fixes an issue 
> with the new mongodb+srv connection scheme when used in an OSGi container 
> (OAK-7486).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7645) Update to MongoDB Java driver 3.8

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549199#comment-16549199
 ] 

Robert Munteanu commented on OAK-7645:
--

Something like https://www.testcontainers.org/ might work as a replacement for 
fongo. It's a trade off where we need to insure that the CI machines and 
developers have docker installed but OTOH we test against real mongo and we are 
not blocked by fongo's lifecycle.

> Update to MongoDB Java driver 3.8
> -
>
> Key: OAK-7645
> URL: https://issues.apache.org/jira/browse/OAK-7645
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.10
>
>
> The updated driver adds compatibility with MongoDB 4.0 and fixes an issue 
> with the new mongodb+srv connection scheme when used in an OSGi container 
> (OAK-7486).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7642) oak-pojosr fails when run twice

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546730#comment-16546730
 ] 

Robert Munteanu commented on OAK-7642:
--

I think [~dulceanu] is looking into this.

> oak-pojosr fails when run twice
> ---
>
> Key: OAK-7642
> URL: https://issues.apache.org/jira/browse/OAK-7642
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: pojosr
>Reporter: Julian Reschke
>Priority: Major
>
> ...because segment store apparently creates the repository folder in the 
> wrong location, and thus doesn't get wiped out on "mvn clean".
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.ConfigTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2 s - 
> in org.apache.jackrabbit.oak.run.osgi.ConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
> [WARNING] Tests run: 10, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 
> 10.327 s - in org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.HybridIndexDisabledTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.149 
> s - in org.apache.jackrabbit.oak.run.osgi.HybridIndexDisabledTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.475 
> s - in org.apache.jackrabbit.oak.run.osgi.JaasConfigSpiTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.547 
> s - in org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.518 
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest
> [ERROR] fullTextSearch(org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest)  
> Time elapsed: 0.518 s  <<< ERROR!
> javax.jcr.ItemExistsException: myFile
> at 
> org.apache.jackrabbit.oak.run.osgi.LuceneSupportTest.fullTextSearch(LuceneSupportTest.groovy:65)
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.MBeanIntegrationTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.522 
> s - in org.apache.jackrabbit.oak.run.osgi.MBeanIntegrationTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.36 s 
> - in org.apache.jackrabbit.oak.run.osgi.NodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.545 
> s - in org.apache.jackrabbit.oak.run.osgi.OakOSGiRepositoryFactoryTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 6.374 
> s <<< FAILURE! - in 
> org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest
> [ERROR] 
> propertyIndexState(org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest)
>   Time elapsed: 6.358 s  <<< ERROR!
> javax.jcr.ItemExistsException: a1
> at 
> org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest.propertyIndexState(PropertyIndexReindexingTest.groovy:50)
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.RepositoryClosedTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.595 
> s - in org.apache.jackrabbit.oak.run.osgi.RepositoryClosedTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.RepositoryShutdownTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.515 
> s - in org.apache.jackrabbit.oak.run.osgi.RepositoryShutdownTest
> [INFO] Running 
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.421 
> s - in org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.703 
> s - in org.apache.jackrabbit.oak.run.osgi.SegmentNodeStoreConfigTest
> [INFO] Running org.apache.jackrabbit.oak.run.osgi.SimpleRepositoryFactoryTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.481 
> s - in org.apache.jackrabbit.oak.run.osgi.SimpleRepositoryFactoryTest
> [INFO] Running 
> org.apache.jackrabbit.oak.run.osgi.TarSegmentNodeStoreConfigTest
> [INFO] Tests run: 1, Failures: 

[jira] [Commented] (OAK-7501) Dependencies on IndexUtils

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489034#comment-16489034
 ] 

Robert Munteanu commented on OAK-7501:
--

[~anchela] - yes, that's exactly what I had in mind. I see that from a code 
size point of view it does not change much, but overall it looks cleaner to me. 
In the end, the choice is yours - whether you think this extra abstraction adds 
value or not.

> Dependencies on IndexUtils
> --
>
> Key: OAK-7501
> URL: https://issues.apache.org/jira/browse/OAK-7501
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: core, indexing, security
>Reporter: angela
>Priority: Major
>  Labels: m12n
> Attachments: OAK-7501-2-adjustsecurity_.patch, 
> OAK-7501-2-index.patch, OAK-7501-adjust_security.patch, 
> OAK-7501-indexing.patch
>
>
> There are several places across the oak security code base where 
> {{IndexUtils}} is used to create index definitions. In addition these usages 
> hardcode implementation details on how the index definitions are stored.
> The goal is to make the security code independant of the very details of the 
> index machinery and ultimately allow the indexing team to change/replace the 
> way indices are store and how requirements like e.g. uniqueness are met.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7501) Dependencies on IndexUtils

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487319#comment-16487319
 ] 

Robert Munteanu commented on OAK-7501:
--

[~anchela] - my suggestion was rather to only pass it once to the repository 
initializer, and then store it an intermediate object. Or to just create a 
method that does all the steps

- create oak:index
- check if index exists
- create index if it does not exist

Of course, I might've missed something as I did not actually try that 
refactoring.

> Dependencies on IndexUtils
> --
>
> Key: OAK-7501
> URL: https://issues.apache.org/jira/browse/OAK-7501
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: core, indexing, security
>Reporter: angela
>Priority: Major
>  Labels: m12n
> Attachments: OAK-7501-adjust_security.patch, OAK-7501-indexing.patch
>
>
> There are several places across the oak security code base where 
> {{IndexUtils}} is used to create index definitions. In addition these usages 
> hardcode implementation details on how the index definitions are stored.
> The goal is to make the security code independant of the very details of the 
> index machinery and ultimately allow the indexing team to change/replace the 
> way indices are store and how requirements like e.g. uniqueness are met.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7408) LuceneIndexProviderService uses default tracker constructor with disabled CoR

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487075#comment-16487075
 ] 

Robert Munteanu commented on OAK-7408:
--

[~catholicon] - sorry for the delayed response, I lost track of this in my 
inbox.

What we could do is have a {{FailOnlyMountInfoProvider}} that throws exceptions 
from all methods. Via reflection (still) we could install this as the 
{{Mounts.DEFAULT_PROVIDER}} field. All would be encapsulated in a Junit rule so 
it does not leak to other tests.

> LuceneIndexProviderService uses default tracker constructor with disabled CoR
> -
>
> Key: OAK-7408
> URL: https://issues.apache.org/jira/browse/OAK-7408
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.8.2, 1.6.11
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.9.0, 1.10
>
>
> {{LuceneIndexProviderService}} creates default constructor for tracker when 
> CoR is disabled. This leads to usage of deafult mount provider for querying.
> \[0]: 
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java#L526



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7499) Dependencies on various 'plugins'

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482535#comment-16482535
 ] 

Robert Munteanu commented on OAK-7499:
--

[~anchela] - changes LGTM. For the components that don't have an {{activate}} 
method that needs to do some work you can drop the {{immediate=true}} flag as 
it's not needed.

> Dependencies on various 'plugins'
> -
>
> Key: OAK-7499
> URL: https://issues.apache.org/jira/browse/OAK-7499
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>Reporter: angela
>Priority: Major
> Attachments: OAK-7499-adjustsecuritycode.patch, 
> OAK-7499-extractplugins.patch
>
>
> subtask of OAK-7498 to drop usage of plugin classes directly from security 
> code base:
> - extract interfaces for managers and provider services
> - replace usage of implementenations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7501) Dependencies on IndexUtils

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16482525#comment-16482525
 ] 

Robert Munteanu commented on OAK-7501:
--

[~anchela] - changes overall look good to me.

Regarding the OSGi annotations - looking at the [\@Reference 
javadoc|https://osgi.org/javadoc/r6/cmpn/org/osgi/service/component/annotations/Reference.html]
 I think you can drop the _bind_ and _cardinality_ fields as the defaults are 
suitable.

While looking at how the new {{QueryIndexCreator}} API is used, we seem to have 
the following pattern:

- get index node from root node
- if index does not exist, create index with the following properties ...

It might be simpler to capture this in the API. One possibility would be to 
have a single method {{ensureIndexDefinitionExists}} which takes the root node 
and the index definition ( possibly as a new object ). Another one would be to 
have a {{QueryIndexCreatorFactory}} ( or similar, I'm bad at naming ) which 
creates a {{QueryIndexCreator}}, given a root node. The created 
{{QueryIndexCreator}} can then expose more fine-grained operations, such as 
{{ensureIndexDefinitionExists}} or the the current 
{{hasIndexDefinition}}/{{createIndexDefintion}} . 

I suggest these since it does not seem that intuitive/safe to pass 
{{NodeBuilder}} objects around, like the old API did.


> Dependencies on IndexUtils
> --
>
> Key: OAK-7501
> URL: https://issues.apache.org/jira/browse/OAK-7501
> Project: Jackrabbit Oak
>  Issue Type: Sub-task
>  Components: core, indexing, security
>Reporter: angela
>Priority: Major
>  Labels: m12n
> Attachments: OAK-7501-adjust_security.patch, OAK-7501-indexing.patch
>
>
> There are several places across the oak security code base where 
> {{IndexUtils}} is used to create index definitions. In addition these usages 
> hardcode implementation details on how the index definitions are stored.
> The goal is to make the security code independant of the very details of the 
> index machinery and ultimately allow the indexing team to change/replace the 
> way indices are store and how requirements like e.g. uniqueness are met.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7470) Remove Usage of ImmutableTree and AbstractTree in Security Code

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468585#comment-16468585
 ] 

Robert Munteanu commented on OAK-7470:
--

[~anchela] - yes, this is probably the best solution at the moment. It was not 
a problematic issue anyway.

> Remove Usage of ImmutableTree and AbstractTree in Security Code
> ---
>
> Key: OAK-7470
> URL: https://issues.apache.org/jira/browse/OAK-7470
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: authorization-cug, core, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
>  Labels: m12n
> Attachments: OAK-7470-tests.patch, OAK-7470.patch
>
>
> With a minor extension to {{TreeProvider}} we would be able to get rid of the 
> direct casting to implementation details like {{ImmutableTree}} and 
> {{AbstractTree}} altogether.
> [~stillalex], patch for review will follow right away.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7470) Remove Usage of ImmutableTree and AbstractTree in Security Code

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463536#comment-16463536
 ] 

Robert Munteanu commented on OAK-7470:
--

[~anchela] - from a backwards compatibility point of view the changes look 
correct and should have no impact on consumers.

FWIW ( and probably nitpicking ) : I am not a heavy user of the Tree API, but I 
wonder if the {{TreeProvider}} is the best place to add this method. This 
interface handles {{NodeState}} -> {{Tree}} conversions so far, now we're 
adding {{Tree}} -> {{NodeState}} which makes it more than {{TreeProvider}} . 
Renaming the class would be breaking BC, so it's a no-go. The new method could 
be moved to a new interface or added to the {{Tree}} interface itself ( not 
sure if feasible ) but it might complicate how we consume that API.

> Remove Usage of ImmutableTree and AbstractTree in Security Code
> ---
>
> Key: OAK-7470
> URL: https://issues.apache.org/jira/browse/OAK-7470
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: authorization-cug, core, security-spi
>Reporter: angela
>Assignee: angela
>Priority: Major
>  Labels: m12n
> Attachments: OAK-7470-tests.patch, OAK-7470.patch
>
>
> With a minor extension to {{TreeProvider}} we would be able to get rid of the 
> direct casting to implementation details like {{ImmutableTree}} and 
> {{AbstractTree}} altogether.
> [~stillalex], patch for review will follow right away.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7414) oak-it-osgi fails on Java 10

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456057#comment-16456057
 ] 

Robert Munteanu commented on OAK-7414:
--

Interesting. Maybe it needs some POM tweaks like we have in Sling? 
https://github.com/apache/sling-org-apache-sling-launchpad-testing/blob/master/pom.xml#L160-L168

> oak-it-osgi fails on Java 10
> 
>
> Key: OAK-7414
> URL: https://issues.apache.org/jira/browse/OAK-7414
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: it
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.10
>
>
> {noformat}
> ERROR: Bundle org.ops4j.pax.exam [1] Error starting 
> link:classpath:META-INF/links/org.ops4j.pax.exam.link 
> (org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam 
> [1](R 1.0): missing requirement [org.ops4j.pax.exam [1](R 1.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0))) 
> [caused by: Unable to resolve org.ops4j.base [5](R 5.0): missing requirement 
> [org.ops4j.base [5](R 5.0)] osgi.wiring.package; 
> (osgi.wiring.package=javax.net.ssl)] Unresolved requirements: 
> [[org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam 
> [1](R 1.0): missing requirement [org.ops4j.pax.exam [1](R 1.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0))) 
> [caused by: Unable to resolve org.ops4j.base [5](R 5.0): missing requirement 
> [org.ops4j.base [5](R 5.0)] osgi.wiring.package; 
> (osgi.wiring.package=javax.net.ssl)] Unresolved requirements: 
> [[org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4148)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
> at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
> at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.base/java.lang.Thread.run(Thread.java:844)
> ERROR: Bundle org.ops4j.pax.exam.inject [2] Error starting 
> link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link 
> (org.osgi.framework.BundleException: Unable to resolve 
> org.ops4j.pax.exam.inject [2](R 2.0): missing requirement 
> [org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused 
> by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0): 
> missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)] 
> osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved 
> requirements: [[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve 
> org.ops4j.pax.exam.inject [2](R 2.0): missing requirement 
> [org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused 
> by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0): 
> missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)] 
> osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved 
> requirements: [[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4148)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
> at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
> at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.base/java.lang.Thread.run(Thread.java:844)
> ERROR: Bundle org.ops4j.pax.exam.extender.service [3] Error starting 
> link:classpath:META-INF/links/org.ops4j.pax.extender.service.link 
> (org.osgi.framework.BundleException: Unable to resolve 
> org.ops4j.pax.exam.extender.service [3](R 3.0): missing requirement 
> [org.ops4j.pax.exam.extender.service [3](R 3.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused 
> by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0): 
> missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)] 
> osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved 
> requirements: [[org.ops4j.pax.exam.extender.service [3](R 3.0)] 

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452266#comment-16452266
 ] 

Robert Munteanu commented on OAK-7182:
--

Sorry, missed that. I was looking mostly at changes like

{noformat}-import static 
com.google.common.util.concurrent.MoreExecutors.sameThreadExecutor;
+import static 
com.google.common.util.concurrent.MoreExecutors.directExecutor;{noformat}

So is the expected result to be able to run on all Guava version between 15 and 
21?

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-7182-guava-21-2.diff, OAK-7182-guava-21.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452257#comment-16452257
 ] 

Robert Munteanu commented on OAK-7182:
--

Have you considered using reflection to access the 'right' methods? It's ugly 
but if properly encapsulated we could get away with running on all available 
Guava versions.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-7182-guava-21-2.diff, OAK-7182-guava-21.diff, 
> guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16443757#comment-16443757
 ] 

Robert Munteanu commented on OAK-7182:
--

With {{Conditional-Package}} external callers would no longer be able to access 
those APIs. And I guess it's bundling most of Guava, so that explains the size 
increase.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-7182-guava-21.diff, guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7414) oak-it-osgi fails on Java 10

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437165#comment-16437165
 ] 

Robert Munteanu commented on OAK-7414:
--

I see some unresolved javax packages:

* javax.net.ssl
* javax.xml.parsers

Also SCR does not resolve as it requires lower java versions:

*  missing requirement [org.apache.felix.scr [15](R 15.0)] osgi.ee; 
(|(&(osgi.ee=JavaSE)(version=1.6))(&(osgi.ee=JavaSE/compact1)(version=1.8)

I would guess that we need to use a more recent version of the Felix framework. 
Perhaps the one we use does not know about Java 10 and fails to export the 
proper packages and also to provide the {{osgi.ee}} capabilities for older Java 
versions.

> oak-it-osgi fails on Java 10
> 
>
> Key: OAK-7414
> URL: https://issues.apache.org/jira/browse/OAK-7414
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: it
>Reporter: Julian Reschke
>Priority: Major
> Fix For: 1.10
>
>
> {noformat}
> ERROR: Bundle org.ops4j.pax.exam [1] Error starting 
> link:classpath:META-INF/links/org.ops4j.pax.exam.link 
> (org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam 
> [1](R 1.0): missing requirement [org.ops4j.pax.exam [1](R 1.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0))) 
> [caused by: Unable to resolve org.ops4j.base [5](R 5.0): missing requirement 
> [org.ops4j.base [5](R 5.0)] osgi.wiring.package; 
> (osgi.wiring.package=javax.net.ssl)] Unresolved requirements: 
> [[org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam 
> [1](R 1.0): missing requirement [org.ops4j.pax.exam [1](R 1.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0))) 
> [caused by: Unable to resolve org.ops4j.base [5](R 5.0): missing requirement 
> [org.ops4j.base [5](R 5.0)] osgi.wiring.package; 
> (osgi.wiring.package=javax.net.ssl)] Unresolved requirements: 
> [[org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4148)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
> at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
> at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.base/java.lang.Thread.run(Thread.java:844)
> ERROR: Bundle org.ops4j.pax.exam.inject [2] Error starting 
> link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link 
> (org.osgi.framework.BundleException: Unable to resolve 
> org.ops4j.pax.exam.inject [2](R 2.0): missing requirement 
> [org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused 
> by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0): 
> missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)] 
> osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved 
> requirements: [[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve 
> org.ops4j.pax.exam.inject [2](R 2.0): missing requirement 
> [org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused 
> by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0): 
> missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)] 
> osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved 
> requirements: [[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4148)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
> at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
> at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> at java.base/java.lang.Thread.run(Thread.java:844)
> ERROR: Bundle org.ops4j.pax.exam.extender.service [3] Error starting 
> link:classpath:META-INF/links/org.ops4j.pax.extender.service.link 
> (org.osgi.framework.BundleException: Unable to resolve 
> org.ops4j.pax.exam.extender.service [3](R 3.0): missing requirement 
> [org.ops4j.pax.exam.extender.service [3](R 3.0)] osgi.wiring.package; 
> 

[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435277#comment-16435277
 ] 

Robert Munteanu commented on OAK-7406:
--

[~reschke] - that might be an issue with Maven plug-in inheritance of maybe a 
side effect of how the maven-bundle-plugin reads configurations. But I guess 
that we don't want automatic inheritance of an export definition - maybe not 
all modules use it, but rather a way of saying "when importing 
com.google.common.*, use this version range ". Which I don't know can work. IMO 
defining the import range centrally and then using the property in specific 
modules is OK.

> relax guava version range in Import-Package declarations
> 
>
> Key: OAK-7406
> URL: https://issues.apache.org/jira/browse/OAK-7406
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Major
> Attachments: OAK-7406.diff
>
>
> We should relax the Guava version to the range that we test with, that is 
> 15.0 to 21 excl.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435069#comment-16435069
 ] 

Robert Munteanu commented on OAK-7406:
--

[~reschke] - inheritance _should_ work. At least you should be able to define 
the property in the parent pom and then use it in the modules that need it.

> relax guava version range in Import-Package declarations
> 
>
> Key: OAK-7406
> URL: https://issues.apache.org/jira/browse/OAK-7406
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Julian Reschke
>Priority: Major
> Attachments: OAK-7406.diff
>
>
> We should relax the Guava version to the range that we test with, that is 
> 15.0 to 21 excl.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409333#comment-16409333
 ] 

Robert Munteanu commented on OAK-6770:
--

The provisioning model works fine for defining variables, but the problem we're 
facing with that is that variables are defined at build time. So imagine we 
have a setting like

{noformat}
[variables]
  sling.home=sling

[configurations]
  org.apache.jackrabbit.foo
 location=${sling.home}/foo

  org.apache.jackrabbit.bar
 location=${sling.home}/bar
{noformat}

The sling.home setting is set in stone to be {{sling}} and I can't change it at 
runtime. In contrast, framework properties can be set at runtime so having 
{{org.apache.jackrabbit.bar}} inspect the {{sling.home}} framework property is 
quite beneficial.

For that reason I'd argue for allowing a fallback to the framework properties 
in Oak components.

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi
> Fix For: 1.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16398395#comment-16398395
 ] 

Robert Munteanu commented on OAK-6770:
--

Using the component configuration allows central definition of properties such 
as {{repository.home}}. IIUC you would propose removing this style of 
definition, which IMO is quite useful and widely used e.g. in Sling

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi
> Fix For: 1.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386199#comment-16386199
 ] 

Robert Munteanu commented on OAK-6770:
--

Thanks adding this here [~mduerig], apparently I missed the question when 
initially scanning it :-(

> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi
> Fix For: 1.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-6770) Convert oak-segment-tar to OSGi R6 annotations

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380269#comment-16380269
 ] 

Robert Munteanu commented on OAK-6770:
--

On the topic of whether we should move, I see the following reasons:

* the old SCR annotations are, well, old and we don't get the benefit of added 
features from newer SCR specifications unless we use the new ones
* the old SCR annotations are proprietary to the Felix project and no longer 
developed. This locks us in to using the specific Maven tooling from Felix 
which is basically in maintenance mode

On the topic on when we should move I would say as early in the dev cycle as 
possible to patch potential regressions. The translation is neither automatic 
nor trivial, so we should do it "soon".

We can mix and match annotations between modules - this is the situation we're 
in now, but I would advise against doing that in the same module - it's 
confusing.

Regarding the more specific fallback config needs we have - framework 
properties, system properties, I suggest we discuss this with someone closer to 
the OSGi specs and maybe there's way to do this in a simplified manner that 
does not require duplicating property names as method definitions and strings.



> Convert oak-segment-tar to OSGi R6 annotations
> --
>
> Key: OAK-6770
> URL: https://issues.apache.org/jira/browse/OAK-6770
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: segment-tar
>Reporter: Robert Munteanu
>Assignee: Francesco Mari
>Priority: Minor
>  Labels: osgi
> Fix For: 1.9.0, 1.10
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (OAK-7263) oak-lucene should not depend on oak-store-document

[Robert Munteanu (JIRA)]

Robert Munteanu created OAK-7263:


 Summary: oak-lucene should not depend on oak-store-document
 Key: OAK-7263
 URL: https://issues.apache.org/jira/browse/OAK-7263
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: lucene
 Environment: {{oak-lucene}} has a hard dependency on 
{{oak-store-document}} and that looks wrong to me. 

{noformat}[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) 
on project oak-lucene: Compilation failure: Compilation failure: 
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[31,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[37,46]
 cannot find symbol
[ERROR]   symbol: class JournalProperty
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[33,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[34,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[38,47]
 cannot find symbol
[ERROR]   symbol: class JournalPropertyBuilder
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[106,12]
 cannot find symbol
[ERROR]   symbol:   class JournalProperty
[ERROR]   location: class 
org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyBuilder
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java:[55,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[29,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[33,31]
 cannot find symbol
[ERROR]   symbol: class JournalProperty
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[22,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[23,54]
 package org.apache.jackrabbit.oak.plugins.document.spi does not exist
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[25,54]
 cannot find symbol
[ERROR]   symbol: class JournalPropertyService
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[33,12]
 cannot find symbol
[ERROR]   symbol:   class JournalPropertyBuilder
[ERROR]   location: class 
org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyService
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[50,5]
 method does not override or implement a method from a supertype
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[61,5]
 method does not override or implement a method from a supertype
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[78,5]
 method does not override or implement a method from a supertype
[ERROR] 
/home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[105,5]
 method 

[jira] [Commented] (OAK-7203) Make MountInfoProvider service in AuthorizationConfigurationImpl optional

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362422#comment-16362422
 ] 

Robert Munteanu commented on OAK-7203:
--

[~stillalex] - I still think we should not make the dependency optional:

{quote}Thinking about this a bit more, I think the current setup is correct. We 
should not allow a 'default' service to be registered or default values to be 
used when it's possible that the value will change. The components must only 
use the 'right' MountInfoProvider from the beginning, otherwise we open the 
door to inconsistent behaviour.{quote}

> Make MountInfoProvider service in AuthorizationConfigurationImpl optional
> -
>
> Key: OAK-7203
> URL: https://issues.apache.org/jira/browse/OAK-7203
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: authorization-cug, core
>Affects Versions: 1.8.1
>Reporter: Oliver Lietz
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.9.0
>
> Attachments: OAK-7203.patch
>
>
> While testing Sling with Oak 1.8 I've observed that 
> AuthorizationConfigurationImpl gets not activated due to missing 
> MountInfoProvider service:
> {noformat}
> @Reference
> private MountInfoProvider mountInfoProvider = 
> Mounts.defaultMountInfoProvider();
> {noformat}
> {noformat}
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Bundleorg.apache.jackrabbit.oak-core (63)
> Implementation Class  
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Default State enabled
> Activationdelayed
> Configuration Policy  optional
> Service Type  singleton
> Services  
> org.apache.jackrabbit.oak.spi.security.authorization.AuthorizationConfiguration
> org.apache.jackrabbit.oak.spi.security.SecurityConfiguration
> PID   
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Reference mountInfoProvider   Unsatisfied
> Service Name: org.apache.jackrabbit.oak.spi.mount.MountInfoProvider
> Cardinality: 1..1
> Policy: static
> Policy Option: reluctant
> No Services bound
> Propertiescomponent.id = 35
> component.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> configurationRanking = 100
> importBehavior = abort
> oak.security.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> readPaths = [/jcr:system/rep:namespaces, /jcr:system/jcr:nodeTypes, 
> /jcr:system/rep:privileges]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7203) Make MountInfoProvider service in AuthorizationConfigurationImpl optional

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362077#comment-16362077
 ] 

Robert Munteanu commented on OAK-7203:
--

I've done some thinking about this and I'm not 100% sure we should move it, so 
I'll discuss on oak-dev.

Pros:
- simpler deployment, fewer bundles to manage

Cons:
- splitting the logic from {{oak-store-composite}} as we should only move one 
implementation class

> Make MountInfoProvider service in AuthorizationConfigurationImpl optional
> -
>
> Key: OAK-7203
> URL: https://issues.apache.org/jira/browse/OAK-7203
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: authorization-cug, core
>Affects Versions: 1.8.1
>Reporter: Oliver Lietz
>Priority: Major
> Attachments: OAK-7203.patch
>
>
> While testing Sling with Oak 1.8 I've observed that 
> AuthorizationConfigurationImpl gets not activated due to missing 
> MountInfoProvider service:
> {noformat}
> @Reference
> private MountInfoProvider mountInfoProvider = 
> Mounts.defaultMountInfoProvider();
> {noformat}
> {noformat}
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Bundleorg.apache.jackrabbit.oak-core (63)
> Implementation Class  
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Default State enabled
> Activationdelayed
> Configuration Policy  optional
> Service Type  singleton
> Services  
> org.apache.jackrabbit.oak.spi.security.authorization.AuthorizationConfiguration
> org.apache.jackrabbit.oak.spi.security.SecurityConfiguration
> PID   
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Reference mountInfoProvider   Unsatisfied
> Service Name: org.apache.jackrabbit.oak.spi.mount.MountInfoProvider
> Cardinality: 1..1
> Policy: static
> Policy Option: reluctant
> No Services bound
> Propertiescomponent.id = 35
> component.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> configurationRanking = 100
> importBehavior = abort
> oak.security.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> readPaths = [/jcr:system/rep:namespaces, /jcr:system/jcr:nodeTypes, 
> /jcr:system/rep:privileges]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346685#comment-16346685
 ] 

Robert Munteanu commented on OAK-7182:
--

Here's the list of APIs I (semi-manually) extracted from oak as of r1822291

{noformat}
org.apache.jackrabbit.oak.plugins.blob;uses:="com.google.common.base,com.google.common.cache,com.google.common.util.concrrent
org.apache.jackrabbit.oak.commons.io;version="1.0.0";uses:="com.google.common.io",
org.apache.jackrabbit.oak.commons;version="1.0.0";uses:="com.google.common.base,com.google.common.collect,
org.apache.jackrabbit.oak.spi.whiteboard;version="1.0.0";uses:="com.google.common.base,
org.apache.jackrabbit.oak.cache;version="1.0.0";uses:="com.google.common.cache,com.google.common.collect,
org.apache.jackrabbit.oak.plugins.index.property.strategy;uses:="com.google.common.base
org.apache.jackrabbit.oak.plugins.nodetype;uses:="com.google.common.base,
org.apache.jackrabbit.oak.plugins.observation.filter;uses:="com.google.common.base
org.apache.jackrabbit.oak.spi.security.authentication.credentials;version="2.1.0";uses:="com.google.common.collect
org.apache.jackrabbit.oak.spi.state;uses:="com.google.common.base,
org.apache.jackrabbit.oak.plugins.memory;uses:="com.google.common.hash,
{noformat}

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346672#comment-16346672
 ] 

Robert Munteanu commented on OAK-7182:
--

I am looking into the Guava packaging and release policy, and it seems that 
they have started following semantic versioning - 
https://github.com/google/guava/wiki/ReleasePolicy . In particular, they will 
only upgrade the major version "
If there are API removals or other incompatible API changes", and that includes 
APIs annotated with {{\@Beta}} . Which in turn for us this means that once we 
incorporate a new version of Guava we should be safe for a longer time. They do 
have breaking changes, for instance this year they had 3 major releases ( and 6 
minor ones ) but version 23 is now 23.6, which may mark a turn in how they 
approach backwards compatibility.

What we can do is either "vet" certain versions, e.g. test with Guava 15 and 
latest ( 23.6 ) and adjust the import versions to be [15,24). Or alternatively 
hope for the test and import [15,).

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7203) Make MountInfoProvider service in AuthorizationConfigurationImpl optional

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346625#comment-16346625
 ] 

Robert Munteanu commented on OAK-7203:
--

Thinking about this a bit more, I think the current setup is correct. We should 
not allow a 'default' service to be registered or default values to be used 
when it's possible that the value will change. The components must only use the 
'right' MountInfoProvider from the beginning, otherwise we open the door to 
inconsistent behaviour.

The only thing that is sub-optimal here is that the {{oak-store-composite}} 
bundle is now required. I don't think that's a huge issue, but we can work 
around it moving the {{MountInfoProviderService}} class from 
{{oak-store-composite}} to {{oak-core}}, so that the {{MountInfoProvider}} 
service can be registered with an empty config without adding an extra bundle.

> Make MountInfoProvider service in AuthorizationConfigurationImpl optional
> -
>
> Key: OAK-7203
> URL: https://issues.apache.org/jira/browse/OAK-7203
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: authorization-cug, core
>Affects Versions: 1.8.1
>Reporter: Oliver Lietz
>Priority: Major
> Attachments: OAK-7203.patch
>
>
> While testing Sling with Oak 1.8 I've observed that 
> AuthorizationConfigurationImpl gets not activated due to missing 
> MountInfoProvider service:
> {noformat}
> @Reference
> private MountInfoProvider mountInfoProvider = 
> Mounts.defaultMountInfoProvider();
> {noformat}
> {noformat}
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Bundleorg.apache.jackrabbit.oak-core (63)
> Implementation Class  
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Default State enabled
> Activationdelayed
> Configuration Policy  optional
> Service Type  singleton
> Services  
> org.apache.jackrabbit.oak.spi.security.authorization.AuthorizationConfiguration
> org.apache.jackrabbit.oak.spi.security.SecurityConfiguration
> PID   
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Reference mountInfoProvider   Unsatisfied
> Service Name: org.apache.jackrabbit.oak.spi.mount.MountInfoProvider
> Cardinality: 1..1
> Policy: static
> Policy Option: reluctant
> No Services bound
> Propertiescomponent.id = 35
> component.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> configurationRanking = 100
> importBehavior = abort
> oak.security.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> readPaths = [/jcr:system/rep:namespaces, /jcr:system/jcr:nodeTypes, 
> /jcr:system/rep:privileges]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7203) Make MountInfoProvider service in AuthorizationConfigurationImpl optional

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344848#comment-16344848
 ] 

Robert Munteanu commented on OAK-7203:
--

The MountInfoProvider reference changing is the same as the repository service 
changing, so I don't think we need the reference to be dynamic.

> Make MountInfoProvider service in AuthorizationConfigurationImpl optional
> -
>
> Key: OAK-7203
> URL: https://issues.apache.org/jira/browse/OAK-7203
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.8.1
>Reporter: Oliver Lietz
>Priority: Major
> Attachments: OAK-7203.patch
>
>
> While testing Sling with Oak 1.8 I've observed that 
> AuthorizationConfigurationImpl gets not activated due to missing 
> MountInfoProvider service:
> {noformat}
> @Reference
> private MountInfoProvider mountInfoProvider = 
> Mounts.defaultMountInfoProvider();
> {noformat}
> {noformat}
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Bundleorg.apache.jackrabbit.oak-core (63)
> Implementation Class  
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Default State enabled
> Activationdelayed
> Configuration Policy  optional
> Service Type  singleton
> Services  
> org.apache.jackrabbit.oak.spi.security.authorization.AuthorizationConfiguration
> org.apache.jackrabbit.oak.spi.security.SecurityConfiguration
> PID   
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Reference mountInfoProvider   Unsatisfied
> Service Name: org.apache.jackrabbit.oak.spi.mount.MountInfoProvider
> Cardinality: 1..1
> Policy: static
> Policy Option: reluctant
> No Services bound
> Propertiescomponent.id = 35
> component.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> configurationRanking = 100
> importBehavior = abort
> oak.security.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> readPaths = [/jcr:system/rep:namespaces, /jcr:system/jcr:nodeTypes, 
> /jcr:system/rep:privileges]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344786#comment-16344786
 ] 

Robert Munteanu commented on OAK-7182:
--

Thinking about how to best 'break away' from a specific Guava version, here's 
my proposal (not tested):

# minimize API exposure from Guava
# replace all Guava usages where alternatives from the JDK exist
# inline Guava in the bundles that import it using {{Conditional-Package}}
# import the Guava packages that we use in the API with a wide, open-ended 
range, e.g. {{[15,)}}

This might work since it allows us to depend on a 'private' version of Guava 
but the APIs will work with other version as well. I am not sure whether we'll 
run into uses constraints due to the Oak bundle importing different versions of 
Guava at some point.

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (OAK-7203) AuthorizationConfigurationImpl is losing its MountInfoProvider

[Robert Munteanu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu resolved OAK-7203.
--
Resolution: Not A Problem

> AuthorizationConfigurationImpl is losing its MountInfoProvider
> --
>
> Key: OAK-7203
> URL: https://issues.apache.org/jira/browse/OAK-7203
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.8.1
>Reporter: Oliver Lietz
>Priority: Major
>
> While testing Sling with Oak 1.8 I've observed that 
> AuthorizationConfigurationImpl is losing its MountInfoProvider:
> {noformat}
> @Reference
> private MountInfoProvider mountInfoProvider = 
> Mounts.defaultMountInfoProvider();
> {noformat}
> {noformat}
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Bundleorg.apache.jackrabbit.oak-core (63)
> Implementation Class  
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Default State enabled
> Activationdelayed
> Configuration Policy  optional
> Service Type  singleton
> Services  
> org.apache.jackrabbit.oak.spi.security.authorization.AuthorizationConfiguration
> org.apache.jackrabbit.oak.spi.security.SecurityConfiguration
> PID   
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Reference mountInfoProvider   Unsatisfied
> Service Name: org.apache.jackrabbit.oak.spi.mount.MountInfoProvider
> Cardinality: 1..1
> Policy: static
> Policy Option: reluctant
> No Services bound
> Propertiescomponent.id = 35
> component.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> configurationRanking = 100
> importBehavior = abort
> oak.security.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> readPaths = [/jcr:system/rep:namespaces, /jcr:system/jcr:nodeTypes, 
> /jcr:system/rep:privileges]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7203) AuthorizationConfigurationImpl is losing its MountInfoProvider

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16341011#comment-16341011
 ] 

Robert Munteanu commented on OAK-7203:
--

Good catch, added in [r1822291|https://svn.apache.org/r1822291] . Should this 
be resolved then?

> AuthorizationConfigurationImpl is losing its MountInfoProvider
> --
>
> Key: OAK-7203
> URL: https://issues.apache.org/jira/browse/OAK-7203
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.8.1
>Reporter: Oliver Lietz
>Priority: Major
>
> While testing Sling with Oak 1.8 I've observed that 
> AuthorizationConfigurationImpl is losing its MountInfoProvider:
> {noformat}
> @Reference
> private MountInfoProvider mountInfoProvider = 
> Mounts.defaultMountInfoProvider();
> {noformat}
> {noformat}
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Bundleorg.apache.jackrabbit.oak-core (63)
> Implementation Class  
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Default State enabled
> Activationdelayed
> Configuration Policy  optional
> Service Type  singleton
> Services  
> org.apache.jackrabbit.oak.spi.security.authorization.AuthorizationConfiguration
> org.apache.jackrabbit.oak.spi.security.SecurityConfiguration
> PID   
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> Reference mountInfoProvider   Unsatisfied
> Service Name: org.apache.jackrabbit.oak.spi.mount.MountInfoProvider
> Cardinality: 1..1
> Policy: static
> Policy Option: reluctant
> No Services bound
> Propertiescomponent.id = 35
> component.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> configurationRanking = 100
> importBehavior = abort
> oak.security.name = 
> org.apache.jackrabbit.oak.security.authorization.AuthorizationConfigurationImpl
> readPaths = [/jcr:system/rep:namespaces, /jcr:system/jcr:nodeTypes, 
> /jcr:system/rep:privileges]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-7182) Make it possible to update Guava

[Robert Munteanu (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16340753#comment-16340753
 ] 

Robert Munteanu commented on OAK-7182:
--

There's at least 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/state/NodeState.java#L388-L393

> Make it possible to update Guava
> 
>
> Key: OAK-7182
> URL: https://issues.apache.org/jira/browse/OAK-7182
> Project: Jackrabbit Oak
>  Issue Type: Wish
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: guava.diff
>
>
> We currently rely on Guava 15, and this affects all users of Oak because they 
> essentially need to use the same version.
> This is an overall issue to investigate what would need to be done in Oak in 
> order to make updates possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)