[jira] [Commented] (OAK-8529) Deregister MBeans on SecurityProviderRegistration component deactivation
[
https://issues.apache.org/jira/browse/OAK-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932115#comment-16932115
]
angela commented on OAK-8529:
-
[~rombert], the patch looks good to me. thanks a lot for providing a test that
illustrates the issue. very much appreciated.
> 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
> org.apache.felix.scr.impl.inject.methods.BaseMethod.in
[jira] [Closed] (OAK-8597) lc command is unable to construct OakDirectory
[ https://issues.apache.org/jira/browse/OAK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta closed OAK-8597. > lc command is unable to construct OakDirectory > -- > > Key: OAK-8597 > URL: https://issues.apache.org/jira/browse/OAK-8597 > Project: Jackrabbit Oak > Issue Type: Bug > Components: run >Affects Versions: 1.10.0, 1.12.0 >Reporter: Jorge Flórez >Assignee: Vikas Saurabh >Priority: Major > Fix For: 1.18.0, 1.10.5 > > > When extracting index info from a repository stored in MongoDB the following > exception is thrown > C:\Users\Jorge Eduardo\Desktop>java -jar oak-run-1.12.0.jar console > mongodb://localhost:37017/rRepo4 > Apache Jackrabbit Oak 1.12.0 > Repository connected in read-only mode. Use '--read-write' for write > operations > Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.12.0, JVM: 1.8.0_191) > Type ':help' or ':h' for help. > --- > /> lc dump "C:\Users\Jorge Eduardo\Desktop\lc" /oak:index/LuceneFullText > ERROR groovy.lang.GroovyRuntimeException: > Could not find matching constructor for: > org.apache.jackrabbit.oak.plugins.index.lucene.directory.OakDirectory(org.apache.jackrabbit.oak.spi.state.ReadOnlyBuilder, > org.apache.jackrabbit.oak.plugins.index.search.IndexDefinition, > java.lang.Boolean) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand.getDirectory > (LuceneCommand.groovy:132) > at org.apache.jackrabbit.oak.console.commands.LuceneCommand$_closure2.doCall > (LuceneCommand.groovy:77) > at java_lang_Runnable$run.call (Unknown Source) > at org.apache.jackrabbit.oak.console.GroovyConsole$OakSh.run > (GroovyConsole.groovy:265) > at org.apache.jackrabbit.oak.console.GroovyConsole.run > (GroovyConsole.groovy:74) > at org.apache.jackrabbit.oak.console.Console.main (Console.java:74) > at org.apache.jackrabbit.oak.run.ConsoleCommand.execute > (ConsoleCommand.java:27) > at org.apache.jackrabbit.oak.run.Main.main (Main.java:49) > The same exception is thrown if I try to dump the index. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OAK-8599) [Direct Binary Access] Initiate upload should return null if feature is disabled
[
https://issues.apache.org/jira/browse/OAK-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta closed OAK-8599.
> [Direct Binary Access] Initiate upload should return null if feature is
> disabled
>
>
> Key: OAK-8599
> URL: https://issues.apache.org/jira/browse/OAK-8599
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob-cloud, blob-cloud-azure, doc
>Affects Versions: 1.16.0, 1.10.4
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.18.0, 1.10.5
>
>
> Documentation at [0] and implementations disagree with Javadoc [1] for
> {{initiateBinaryUpload()}} regarding determining if the feature is enabled.
> At [0] it indicates that either a null return value or empty list of upload
> URIs indicates the feature is disabled, but [1] indicates only a null return
> value to indicate the feature is disabled.
> [0] -
> https://jackrabbit.apache.org/oak/docs/features/direct-binary-access.html
> [1] -
> https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/api/JackrabbitValueFactory.html#initiateBinaryUpload-long-int-
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8298) [Direct Binary Access] Blobs that are directly uploaded are not tracked by BlobIdTracker
[
https://issues.apache.org/jira/browse/OAK-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Gupta closed OAK-8298.
> [Direct Binary Access] Blobs that are directly uploaded are not tracked by
> BlobIdTracker
>
>
> Key: OAK-8298
> URL: https://issues.apache.org/jira/browse/OAK-8298
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob-cloud, blob-cloud-azure, blob-plugins
>Affects Versions: 1.16.0, 1.10.4
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
> Fix For: 1.18.0, 1.10.5
>
>
> Blobs that are uploaded to the content repository are supposed to be tracked
> by the {{BlobIdTracker}} once the blob is saved. This is done for blobs
> uploaded the traditional way in {{DataStoreBlobStore.writeBlob()}} [0].
> For blobs uploaded directly, they do not go through this method and so the
> blob ID is never added to the {{BlobIdTracker}}. This has impact on DSGC as
> the {{MarkSweepGarbageCollector}} relies on the {{BlobIdTracker}} to provide
> an accurate accounting of the blob IDs in the blob store to determine which
> ones to retain and which to delete.
> This should be a pretty easy fix. All direct uploads pass through
> {{DataStoreBlobStore.completeBlobUpload()}} [1], and we have at that point
> access to the {{DataRecord}} created by the direct upload. We can get the
> blob ID from the {{DataRecord}} and add it to the {{BlobIdTracker}} there.
> [0] -
> [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java#L241]
> [1] -
> [https://github.com/apache/jackrabbit-oak/blob/46cde5ee49622c94bc95648edf84cf4c00ae1d58/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java#L723]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OAK-8586) Update Oak trunk and 1.10 to Jackrabbit 2.18.3
[ https://issues.apache.org/jira/browse/OAK-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Gupta closed OAK-8586. > Update Oak trunk and 1.10 to Jackrabbit 2.18.3 > -- > > Key: OAK-8586 > URL: https://issues.apache.org/jira/browse/OAK-8586 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.18.0, 1.10.5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OAK-8631) Determining correct upload domain fails if string is empty
[
https://issues.apache.org/jira/browse/OAK-8631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Ryan resolved OAK-8631.
Resolution: Fixed
Fixed in
[r1867074|https://svn.apache.org/viewvc?view=revision&revision=1867074].
> Determining correct upload domain fails if string is empty
> --
>
> Key: OAK-8631
> URL: https://issues.apache.org/jira/browse/OAK-8631
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob-cloud-azure
>Reporter: Matt Ryan
>Assignee: Matt Ryan
>Priority: Major
>
> Need to check for {{Strings.isNullOrEmpty(domain)}} and then assign the
> domain to the default value if the upload domain override is not set.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (OAK-8631) Determining correct upload domain fails if string is empty
Matt Ryan created OAK-8631:
--
Summary: Determining correct upload domain fails if string is empty
Key: OAK-8631
URL: https://issues.apache.org/jira/browse/OAK-8631
Project: Jackrabbit Oak
Issue Type: Bug
Components: blob-cloud-azure
Reporter: Matt Ryan
Assignee: Matt Ryan
Need to check for {{Strings.isNullOrEmpty(domain)}} and then assign the domain
to the default value if the upload domain override is not set.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (OAK-8630) Build Jackrabbit Oak #2383 failed
Hudson created OAK-8630: --- Summary: Build Jackrabbit Oak #2383 failed Key: OAK-8630 URL: https://issues.apache.org/jira/browse/OAK-8630 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #2383 has failed. First failed run: [Jackrabbit Oak #2383|https://builds.apache.org/job/Jackrabbit%20Oak/2383/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2383/console] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (OAK-8621) Build Jackrabbit Oak #2377 failed
[ https://issues.apache.org/jira/browse/OAK-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931581#comment-16931581 ] Hudson commented on OAK-8621: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2382|https://builds.apache.org/job/Jackrabbit%20Oak/2382/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2382/console] > Build Jackrabbit Oak #2377 failed > - > > Key: OAK-8621 > URL: https://issues.apache.org/jira/browse/OAK-8621 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #2377 has failed. > First failed run: [Jackrabbit Oak > #2377|https://builds.apache.org/job/Jackrabbit%20Oak/2377/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/2377/console] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (OAK-8624) oak-run: tests leak mapd temp files
[
https://issues.apache.org/jira/browse/OAK-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931524#comment-16931524
]
Julian Reschke commented on OAK-8624:
-
trunk: [r1867061|http://svn.apache.org/r1867061]
> oak-run: tests leak mapd temp files
> ---
>
> Key: OAK-8624
> URL: https://issues.apache.org/jira/browse/OAK-8624
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.18.0
>
> Attachments: OAK-8624.diff
>
>
> This is because {{MapDBMapFactory}} is backed by temporary DB, but that one
> is never closed.
> Fix:
> - make it {{closeable}}
> - adapt test case and use in {{RecoveryCommand}}
> However, {{RecoveryCommand}} sets the {{MapFactory}} instance globally, and
> never resets it. Thus, if the factory is indeed closed, subsequent tests will
> fail. So, in {{RecoveryCommand}}, restore the default factory when done.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (OAK-8624) oak-run: tests leak mapd temp files
[
https://issues.apache.org/jira/browse/OAK-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8624:
Labels: candidate_oak_1_10 (was: )
> oak-run: tests leak mapd temp files
> ---
>
> Key: OAK-8624
> URL: https://issues.apache.org/jira/browse/OAK-8624
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10
> Fix For: 1.18.0
>
> Attachments: OAK-8624.diff
>
>
> This is because {{MapDBMapFactory}} is backed by temporary DB, but that one
> is never closed.
> Fix:
> - make it {{closeable}}
> - adapt test case and use in {{RecoveryCommand}}
> However, {{RecoveryCommand}} sets the {{MapFactory}} instance globally, and
> never resets it. Thus, if the factory is indeed closed, subsequent tests will
> fail. So, in {{RecoveryCommand}}, restore the default factory when done.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (OAK-8624) oak-run: tests leak mapd temp files
[
https://issues.apache.org/jira/browse/OAK-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-8624.
-
Fix Version/s: 1.18.0
Resolution: Fixed
> oak-run: tests leak mapd temp files
> ---
>
> Key: OAK-8624
> URL: https://issues.apache.org/jira/browse/OAK-8624
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 1.18.0
>
> Attachments: OAK-8624.diff
>
>
> This is because {{MapDBMapFactory}} is backed by temporary DB, but that one
> is never closed.
> Fix:
> - make it {{closeable}}
> - adapt test case and use in {{RecoveryCommand}}
> However, {{RecoveryCommand}} sets the {{MapFactory}} instance globally, and
> never resets it. Thus, if the factory is indeed closed, subsequent tests will
> fail. So, in {{RecoveryCommand}}, restore the default factory when done.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8629) Node bundling exposes hidden properties
[
https://issues.apache.org/jira/browse/OAK-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931507#comment-16931507
]
Marcel Reutegger commented on OAK-8629:
---
The implementation actually exposes more than just the
{{:doc-has-child-bundled}} property. In some cases it will also expose
{{jcr:content/:doc-has-child-non-bundled}}.
Updated the test: http://svn.apache.org/r1867060
> Node bundling exposes hidden properties
> ---
>
> Key: OAK-8629
> URL: https://issues.apache.org/jira/browse/OAK-8629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.16.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.18.0
>
>
> The DocumentNodeStore node bundling feature may expose a hidden internal
> property when a bundled node structure is deleted and re-created with a
> non-bundling nodetype.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (OAK-8629) Node bundling exposes hidden properties
[ https://issues.apache.org/jira/browse/OAK-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-8629: -- Summary: Node bundling exposes hidden properties (was: Node bundling exposes hidden property) > Node bundling exposes hidden properties > --- > > Key: OAK-8629 > URL: https://issues.apache.org/jira/browse/OAK-8629 > Project: Jackrabbit Oak > Issue Type: Bug > Components: documentmk >Affects Versions: 1.16.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.18.0 > > > The DocumentNodeStore node bundling feature may expose a hidden internal > property when a bundled node structure is deleted and re-created with a > non-bundling nodetype. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (OAK-8629) Node bundling exposes hidden property
[
https://issues.apache.org/jira/browse/OAK-8629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931483#comment-16931483
]
Marcel Reutegger commented on OAK-8629:
---
Added an ignored test that reproduces the problem:
http://svn.apache.org/r1867057
The recreated node has a {{:doc-has-child-bundled}} property.
> Node bundling exposes hidden property
> -
>
> Key: OAK-8629
> URL: https://issues.apache.org/jira/browse/OAK-8629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.16.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.18.0
>
>
> The DocumentNodeStore node bundling feature may expose a hidden internal
> property when a bundled node structure is deleted and re-created with a
> non-bundling nodetype.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (OAK-8629) Node bundling exposes hidden property
Marcel Reutegger created OAK-8629: - Summary: Node bundling exposes hidden property Key: OAK-8629 URL: https://issues.apache.org/jira/browse/OAK-8629 Project: Jackrabbit Oak Issue Type: Bug Components: documentmk Affects Versions: 1.16.0 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.18.0 The DocumentNodeStore node bundling feature may expose a hidden internal property when a bundled node structure is deleted and re-created with a non-bundling nodetype. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931472#comment-16931472
]
Vikas Saurabh commented on OAK-8628:
bq. So maybe MemoryChildNodeEntry should enforce the contract in the
constructor???
+1 to this anyway.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use {{isHiddenPath()}} instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931469#comment-16931469
]
Vikas Saurabh commented on OAK-8628:
[~reschke], while indeed it seems that {{TraversingCursor}} for
{{ALL_CHILDREN}} and {{PARENT}} path restrictions is preparing
{{MemoryNodeState}} with name to be path to node. But, then I think that
{code}
currentPath = PathUtils.concat(parentPath, name);
{code}
should've thrown an {{IllegalArgumentException}}. Could you point me to a test
that showed the stack mentioned in description.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use {{isHiddenPath()}} instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8624) oak-run: tests leak mapd temp files
[
https://issues.apache.org/jira/browse/OAK-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931442#comment-16931442
]
Marcel Reutegger commented on OAK-8624:
---
Looks good to me. +1
> oak-run: tests leak mapd temp files
> ---
>
> Key: OAK-8624
> URL: https://issues.apache.org/jira/browse/OAK-8624
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Attachments: OAK-8624.diff
>
>
> This is because {{MapDBMapFactory}} is backed by temporary DB, but that one
> is never closed.
> Fix:
> - make it {{closeable}}
> - adapt test case and use in {{RecoveryCommand}}
> However, {{RecoveryCommand}} sets the {{MapFactory}} instance globally, and
> never resets it. Thus, if the factory is indeed closed, subsequent tests will
> fail. So, in {{RecoveryCommand}}, restore the default factory when done.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931362#comment-16931362
]
Julian Reschke edited comment on OAK-8628 at 9/17/19 1:03 PM:
--
Looking some more I see in {{Cursors}}:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
{{ChildNodeEnty.getName()}}. How can that be a full path???
The reason seems to be in the same class, {{TraversingCursor}}, which costructs
the entries with a path instead of a name.
So maybe {{MemoryChildNodeEntry}} should enforce the contract in the
constructor???
was (Author: reschke):
Looking some more I see in {{Cursors}}:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
{{ChildNodeEnty.getName()}}. How can that be a full path???
The reason seems to be in the same class, `TraversingCursor`, which costructs
the entries with a path instead of a name.
So maybe `MemoryChildNodeEntry` should enforce the contract in the
constructor???
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use {{isHiddenPath()}} instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931362#comment-16931362
]
Julian Reschke edited comment on OAK-8628 at 9/17/19 1:02 PM:
--
Looking some more I see in {{Cursors}}:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
{{ChildNodeEnty.getName()}}. How can that be a full path???
The reason seems to be in the same class, `TraversingCursor`, which costructs
the entries with a path instead of a name.
So maybe `MemoryChildNodeEntry` should enforce the contract in the
constructor???
was (Author: reschke):
Looking some more I see in `Cursors`:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
`ChildNodeEnty.getName()`. How can that be a full path???
The reason seems to be in the same class, `TraversingCursor`, which costructs
the entries with a path instead of a name.
So maybe `MemoryChildNodeEntry` should enforce the contract in the
constructor???
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use `isHiddenPath()` instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8628:
Description:
For instance with "/test" from
{noformat}
10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
java.lang.Exception: call stack
at
org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
at
org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
at
org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
{noformat}
We should either change doc and impl to handle paths, or enforce the contract
and chagne other code to use {{isHiddenPath()}} instead.
was:
For instance with "/test" from
{noformat}
10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
java.lang.Exception: call stack
at
org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
at
org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
at
org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
{noformat}
We should either change doc and impl to handle paths, or enforce the contract
and chagne other code to use `isHiddenPath()` instead.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use {{isHiddenPath()}} instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931362#comment-16931362
]
Julian Reschke edited comment on OAK-8628 at 9/17/19 12:48 PM:
---
Looking some more I see in `Cursors`:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
`ChildNodeEnty.getName()`. How can that be a full path???
The reason seems to be in the same class, `TraversingCursor`, which costructs
the entries with a path instead of a name.
So maybe `MemoryChildNodeEntry` should enforce the contract in the
constructor???
was (Author: reschke):
Looking some more I see in `Cursors`:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
`ChildNodeEnty.getName()`. How can that be a full path???
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use `isHiddenPath()` instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931362#comment-16931362
]
Julian Reschke commented on OAK-8628:
-
Looking some more I see in `Cursors`:
{noformat}
ChildNodeEntry entry = iterator.next();
readCount++;
if (readCount % 1000 == 0) {
FilterIterators.checkReadLimit(readCount, settings);
LOG.warn("Traversed " + readCount + " nodes with filter
" + filter + "; consider creating an index or changing the query");
}
NodeState node = entry.getNodeState();
String name = entry.getName();
if (NodeStateUtils.isHidden(name)) {
continue;
}
currentPath = PathUtils.concat(parentPath, name);
{noformat}
So what get's tested for "hidden" is the return value of
`ChildNodeEnty.getName()`. How can that be a full path???
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use `isHiddenPath()` instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
[
https://issues.apache.org/jira/browse/OAK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931214#comment-16931214
]
Vikas Saurabh commented on OAK-8628:
Btw, note that {{isHiddenPath}} returns true if any of the path fragments in a
given path starts with {{:}}. So, all of these would return true /:foo,
/foo/:foo1and /foo/:foo1/foo2.
So, this is not an exact substitute I think.
> NodeStateUtils.isHidden expects names but get's called with paths
> -
>
> Key: OAK-8628
> URL: https://issues.apache.org/jira/browse/OAK-8628
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: store-spi
>Reporter: Julian Reschke
>Priority: Major
>
> For instance with "/test" from
> {noformat}
> 10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
> java.lang.Exception: call stack
>at
> org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
>at
> org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
>at
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
> {noformat}
> We should either change doc and impl to handle paths, or enforce the contract
> and chagne other code to use `isHiddenPath()` instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (OAK-8628) NodeStateUtils.isHidden expects names but get's called with paths
Julian Reschke created OAK-8628:
---
Summary: NodeStateUtils.isHidden expects names but get's called
with paths
Key: OAK-8628
URL: https://issues.apache.org/jira/browse/OAK-8628
Project: Jackrabbit Oak
Issue Type: Bug
Components: store-spi
Reporter: Julian Reschke
For instance with "/test" from
{noformat}
10:30:12.983 ERROR [main] NodeStateUtils.java:50/test
java.lang.Exception: call stack
at
org.apache.jackrabbit.oak.spi.state.NodeStateUtils.isHidden(NodeStateUtils.java:50)
at
org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.fetchNext(Cursors.java:348)
at
org.apache.jackrabbit.oak.plugins.index.Cursors$TraversingCursor.hasNext(Cursors.java:327)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.nextInternal(SelectorImpl.java:515)
at
org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:508)
{noformat}
We should either change doc and impl to handle paths, or enforce the contract
and chagne other code to use `isHiddenPath()` instead.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
