[jira] [Commented] (OAK-10779) Build Jackrabbit/jackrabbit-oak-trunk #1451 failed
[ https://issues.apache.org/jira/browse/OAK-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844691#comment-17844691 ] Hudson commented on OAK-10779: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-trunk #1461|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1461/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1461/console] > Build Jackrabbit/jackrabbit-oak-trunk #1451 failed > -- > > Key: OAK-10779 > URL: https://issues.apache.org/jira/browse/OAK-10779 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1451 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1451|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1451/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1451/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10791) Build Jackrabbit/jackrabbit-oak-trunk-java17 #18 failed
Hudson created OAK-10791: Summary: Build Jackrabbit/jackrabbit-oak-trunk-java17 #18 failed Key: OAK-10791 URL: https://issues.apache.org/jira/browse/OAK-10791 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit/jackrabbit-oak-trunk-java17 #18 has failed. First failed run: [Jackrabbit/jackrabbit-oak-trunk-java17 #18|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk-java17/18/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk-java17/18/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10790) FullTextBinaryTextExtractor incorrectly identifies a text file as CSV and fails while parsing it
Nitin Gupta created OAK-10790:
-
Summary: FullTextBinaryTextExtractor incorrectly identifies a text
file as CSV and fails while parsing it
Key: OAK-10790
URL: https://issues.apache.org/jira/browse/OAK-10790
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Nitin Gupta
FullTextBinaryTextExtractor incorrectly identifies a text file as CSV and fails
while parsing it.
A text file consisting of content with a strucutre similar to a CSV file like -
{code:java}
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
a,b
{code}
even the extension of .txt gets parsed by CSV parser via the AutoDetectorParser
in tika.
This leads to a run time exception in an OSGI based setup if the commons-csv
bundle is not provided.
{code:java}
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/csv/CSVFormat
at
org.apache.tika.parser.csv.TextAndCSVParser.parse(TextAndCSVParser.java:169)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:281)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:281)
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143)
at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:159)
at
org.apache.jackrabbit.oak.osgi.TikaExtractionOsgiIT.assertFileContains(TikaExtractionOsgiIT.java:215)
at
org.apache.jackrabbit.oak.osgi.TikaExtractionOsgiIT.text2(TikaExtractionOsgiIT.java:204)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runLeafWithRetry(ContainerTestRunner.java:97)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:75)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:43)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
... 25 more {code}
I will add a test to demonstrate this.
We should handle this gracefully in oak and maybe use the parser based on the
file extension or mime type as a backup for the AutoDetectParser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10784) o.a.j.o.plugins.migration.version.VersionableEditor should create the version storage node, if needed
[ https://issues.apache.org/jira/browse/OAK-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke resolved OAK-10784. -- Resolution: Fixed > o.a.j.o.plugins.migration.version.VersionableEditor should create the version > storage node, if needed > - > > Key: OAK-10784 > URL: https://issues.apache.org/jira/browse/OAK-10784 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > > The method VersionableEditor#createEmptyHistory() is called if the migration > of versions is disabled, but the node type of a migrated node strictly > requires it to be versionable, because it inherits from mix:versionable (so > that mix:versionable can't simply be removed). This may fail if the version > storage node has not been explicitly created before the migration. Just > creating the necessary node would be a more straightforward behavior. > Also we should change the name of that method, see OAK-10783. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10784) o.a.j.o.plugins.migration.version.VersionableEditor should create the version storage node, if needed
[ https://issues.apache.org/jira/browse/OAK-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844620#comment-17844620 ] Manfred Baedke commented on OAK-10784: -- trunk (1.64.0): [86befafe|https://github.com/apache/jackrabbit-oak/commit/86befafe6711576c4801141a9069b899f0d69425] > o.a.j.o.plugins.migration.version.VersionableEditor should create the version > storage node, if needed > - > > Key: OAK-10784 > URL: https://issues.apache.org/jira/browse/OAK-10784 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > > The method VersionableEditor#createEmptyHistory() is called if the migration > of versions is disabled, but the node type of a migrated node strictly > requires it to be versionable, because it inherits from mix:versionable (so > that mix:versionable can't simply be removed). This may fail if the version > storage node has not been explicitly created before the migration. Just > creating the necessary node would be a more straightforward behavior. > Also we should change the name of that method, see OAK-10783. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10784) o.a.j.o.plugins.migration.version.VersionableEditor should create the version storage node, if needed
[ https://issues.apache.org/jira/browse/OAK-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844619#comment-17844619 ] Manfred Baedke edited comment on OAK-10784 at 5/8/24 10:31 AM: --- ??Under what circumstances would there ever by an Oak repository without version storage? Is there some buggy initialization code out there??? No, as soon as a Repo actually gets started on the migrated NodeStore, the version storage will be created. The migration works on NodeStore level, so there is no target repository during the process, just the NodeStore. was (Author: baedke): ??Under what circumstances would there ever by an Oak repository without version storage? Is there some buggy initialization code out there??? No, as soon as a Repo actually gets started in the migrated NodeStore, the version storage will be created. The migration works on NodeStore level, so there is no target repository during the process, just the NodeStore. > o.a.j.o.plugins.migration.version.VersionableEditor should create the version > storage node, if needed > - > > Key: OAK-10784 > URL: https://issues.apache.org/jira/browse/OAK-10784 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > > The method VersionableEditor#createEmptyHistory() is called if the migration > of versions is disabled, but the node type of a migrated node strictly > requires it to be versionable, because it inherits from mix:versionable (so > that mix:versionable can't simply be removed). This may fail if the version > storage node has not been explicitly created before the migration. Just > creating the necessary node would be a more straightforward behavior. > Also we should change the name of that method, see OAK-10783. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10784) o.a.j.o.plugins.migration.version.VersionableEditor should create the version storage node, if needed
[ https://issues.apache.org/jira/browse/OAK-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844619#comment-17844619 ] Manfred Baedke commented on OAK-10784: -- ??Under what circumstances would there ever by an Oak repository without version storage? Is there some buggy initialization code out there??? No, as soon as a Repo actually gets started in the migrated NodeStore, the version storage will be created. The migration works on NodeStore level, so there is no target repository during the process, just the NodeStore. > o.a.j.o.plugins.migration.version.VersionableEditor should create the version > storage node, if needed > - > > Key: OAK-10784 > URL: https://issues.apache.org/jira/browse/OAK-10784 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > > The method VersionableEditor#createEmptyHistory() is called if the migration > of versions is disabled, but the node type of a migrated node strictly > requires it to be versionable, because it inherits from mix:versionable (so > that mix:versionable can't simply be removed). This may fail if the version > storage node has not been explicitly created before the migration. Just > creating the necessary node would be a more straightforward behavior. > Also we should change the name of that method, see OAK-10783. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10784) o.a.j.o.plugins.migration.version.VersionableEditor should create the version storage node, if needed
[ https://issues.apache.org/jira/browse/OAK-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844560#comment-17844560 ] Julian Reschke commented on OAK-10784: -- Under what circumstances would there *ever* by an Oak repository without version storage? Is there some buggy initialization code out there? > o.a.j.o.plugins.migration.version.VersionableEditor should create the version > storage node, if needed > - > > Key: OAK-10784 > URL: https://issues.apache.org/jira/browse/OAK-10784 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Manfred Baedke >Assignee: Manfred Baedke >Priority: Major > Fix For: 1.64.0 > > > The method VersionableEditor#createEmptyHistory() is called if the migration > of versions is disabled, but the node type of a migrated node strictly > requires it to be versionable, because it inherits from mix:versionable (so > that mix:versionable can't simply be removed). This may fail if the version > storage node has not been explicitly created before the migration. Just > creating the necessary node would be a more straightforward behavior. > Also we should change the name of that method, see OAK-10783. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10779) Build Jackrabbit/jackrabbit-oak-trunk #1451 failed
[ https://issues.apache.org/jira/browse/OAK-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844548#comment-17844548 ] Hudson commented on OAK-10779: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-trunk #1460|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1460/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1460/console] > Build Jackrabbit/jackrabbit-oak-trunk #1451 failed > -- > > Key: OAK-10779 > URL: https://issues.apache.org/jira/browse/OAK-10779 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1451 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1451|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1451/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1451/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
