[
https://issues.apache.org/jira/browse/LUCENE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348253#comment-16348253
]
Julien Massenet commented on LUCENE-8146:
-----------------------------------------
Dawid and Robert: this was actually not new code - this is just code that was
already present in the code-base, just duplicated:
*
[https://github.com/apache/lucene-solr/blob/branch_7x/solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java#L174]
*
[https://github.com/apache/lucene-solr/blob/branch_7x/solr/core/src/java/org/apache/solr/core/BlobRepository.java#L56]
*
[https://github.com/apache/lucene-solr/blob/branch_7x/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L138]
I only added a class in an effort to reduce the duplication, but I did not
introduce that behavior (of using Random instead of the RandomizedContext).
I've attached a newer patch version which copy-paste the changes at all
affected locations instead. It is still using Random directly, as it was before.
For reference, here is the stacktrace you get when you encounter the issue:
{code:java}
breakingTest(org.apache.lucene.seed_issue.SomeClassUsingStringHelperTest) Time
elapsed: 0.006 s <<< ERROR!
java.lang.ExceptionInInitializerError
at
org.apache.lucene.seed_issue.SomeClassUsingStringHelperTest.breakingTest(SomeClassUsingStringHelperTest.java:10)
Caused by: java.lang.NumberFormatException: For input string: ""
at
org.apache.lucene.seed_issue.SomeClassUsingStringHelperTest.breakingTest(SomeClassUsingStringHelperTest.java:10){code}
(So no reference to the class in question, which made tracking down the issue
painful)
I didn't check the RandomizedRunner part, but one think to note in this case:
it seems like any error that would happen in RandomizedRunner would only affect
the Lucene unit tests or clients using the test framework, no ? Whereas the
problem with {{tests.seed}} parsing & {{StringHelper}} happens in production
code, so it impacts client code that depend on Lucene, even if it doesn't use
its test framework.
> Unit tests using StringHelper fail with ExceptionInInitializerError for maven
> surefire >= 2.18
> ----------------------------------------------------------------------------------------------
>
> Key: LUCENE-8146
> URL: https://issues.apache.org/jira/browse/LUCENE-8146
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 7.2.1
> Reporter: Julien Massenet
> Priority: Minor
> Attachments: LUCENE-8146-seed_issue.tar.gz, LUCENE-8146_v1.patch,
> LUCENE-8146_v2.patch
>
>
> This happens when multiple conditions are met:
> * The client code is built with Maven
> * To execute its unit tests, the client code relies on the
> {{maven-surefire-plugin}}, with a version greater than 2.17 (last working
> version)
> * The client code uses the {{org.apache.lucene.util.StringHelper}} class
> (even transitively)
> * The client is configured as with the standard Lucene maven build (i.e. it
> is possible to fix the test seed using the {{tests.seed}} property)
> There was a change in Surefire's behavior starting with 2.18: when a property
> is empty, instead of not sending it to the test runner, it will be sent with
> an empty value.
> This behavior can be observed with the attached sample project:
> * {{mvn test}}: fails with a {{java.lang.ExceptionInInitializerError}}
> * {{mvn test -Dtests.seed=123456}}: succeeds because the property is set to
> a real value
> * {{mvn test -Dsurefire.version=2.17}}: succeeds because the surefire
> version is lower than 2.18
> Attached is a patch (built against \{{branch_7x}}) that centralizes accesses
> to the {{tests.seed}} system property; it also makes sure that if it is
> empty, it is treated as absent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
