-
Notifications
You must be signed in to change notification settings - Fork 795
Remove extra solr.xml and other config setup for tests that are not needed #3988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR removes unnecessary solr.xml file copying operations during test setup across multiple test classes, simplifying test initialization code.
- Removed the unused
copyMinFullSetuphelper method from SolrTestCaseJ4 - Eliminated solr.xml copying from test setup methods across multiple test files
- Removed unused helper methods and imports that became redundant after cleanup
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| solr/test-framework/src/java/org/apache/solr/SolrTestCaseJ4.java | Removed unused copyMinFullSetup method that copied solr.xml |
| solr/solrj/src/test/org/apache/solr/client/solrj/impl/LB2SolrClientTest.java | Removed solr.xml copying from setUp and removed unused helper methods (getUrl, getConfDir, getSolrXmlFile) |
| solr/solrj/src/test/org/apache/solr/client/solrj/TestLBHttpSolrClient.java | Removed solr.xml copying from setUp and removed unused helper methods (getUrl, getConfDir, getSolrXmlFile) |
| solr/core/src/test/org/apache/solr/security/BasicAuthStandaloneTest.java | Removed solr.xml and config file copying from setUp, removed unused helper methods and constants, simplified Properties initialization |
| solr/core/src/test/org/apache/solr/schema/TestBinaryField.java | Removed solr.xml copying from beforeTest and removed unused SolrTestCaseJ4 import |
| solr/core/src/test/org/apache/solr/response/TestRawTransformer.java | Removed solr.xml copying from initStandalone, simplified Properties initialization, and removed unused SolrTestCaseJ4 import |
| solr/core/src/test/org/apache/solr/jersey/JerseyApplicationSharingTest.java | Removed unused collection and confDir constants |
| solr/core/src/test/org/apache/solr/handler/V2StandaloneTest.java | Removed solr.xml copying and unused Files import |
| solr/core/src/test/org/apache/solr/handler/TestRestoreCore.java | Removed solr.xml copying, simplified Properties initialization, and removed unnecessary "throws Exception" from test method signature |
| solr/core/src/test/org/apache/solr/handler/TestReplicationHandlerDiskOverFlow.java | Added System property configuration for URL allow-list checks |
| solr/core/src/test/org/apache/solr/handler/TestReplicationHandlerBackup.java | Removed solr.xml copying and simplified Properties initialization |
| solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java | Removed solr.xml copying, simplified Properties initialization, and removed unused StandardCopyOption import |
| solr/core/src/test/org/apache/solr/TestCustomCoreProperties.java | Removed solr.xml copying, renamed variable from src_dir to srcDir for better Java naming convention, and simplified Properties initialization |
| solr/core/src/test/org/apache/solr/SolrTestCaseJ4Test.java | Removed solr.xml copying from beforeClass |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@dsmiley I'd love a review of this... |
| System.clearProperty(TEST_URL_ALLOW_LIST); | ||
| System.clearProperty("solr.security.allow.urls.enabled"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clearing properties in an @After or @AfterClass is always pointless since our test infra does that for us. Removing them everywhere would be a nice separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion, will do that.
| Path solrHomeTmp = createTempDir(); | ||
| PathUtils.copyDirectory( | ||
| TEST_HOME().resolve("configsets/minimal/conf"), solrHomeTmp.resolve("conf")); | ||
| Files.copy(TEST_HOME().resolve("solr.xml"), solrHomeTmp.resolve("solr.xml")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So why is solr.xml copying no longer necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dunno. The test still runs. Sometimes I think that some of this code just got copy/pasted over and over from test to test. Maybe it mattered for one test, and then it just kept living like a zombie. If you are really itnerested I can investigate (i.e ask Little Buddy what the deal is!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a bit irresponsible to do this on the grounds that tests pass, without looking into the matter any further. Take a look at solr/core/src/test-files/solr/solr.xml. There are comments there about why the settings are different (e.g. distribUpdateSoTimeout) and various customizability that (unfortunately) our standard solr.xml doesn't have (but should).
I can see that the current situation could use improvement. Probably a separate PR should tackle that. Maybe that solr.xml should be in the solr-test-framework JAR as a resource that the test infra can reference and be used by 3rd parties. But also need a simple one-liner to install it into provided Path dir. Or alternatively a new property to the node props which contains a path to where solr.xml is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that I documented the rule's startSolr as follows, meaning it has good test defaults. But only EmbeddedSolrServerTestRule follows this. I suppose then we have room to improve the Jetty side, after which it will indeed make sense to not copy a general test solr.xml.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dsmiley I have added https://issues.apache.org/jira/browse/SOLR-18053 to track your suggestion. I've also linked it to a VERY old JIRA of mine, https://issues.apache.org/jira/browse/SOLR-15788 which seeks to get us away from the kitchen sink approach as well.
| private static final Path CONF_DIR = | ||
| ROOT_DIR.resolve("configsets").resolve("configset-2").resolve("conf"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears you've changed this test to no longer use configset-2. Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I removed the vairuable and it still ran... I went and looked and yeah, they pretty much are the same:
Solrconfig files: Nearly identical except for a comment difference:
configset-1: Generic comment about being a "kitchen sink" config file for tests
configset-2: Specific comment stating "Small solrconfig with no /get handler defined, for use in TestConfigSets#testConfigSetOnReload"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets not change this in this PR.
"collection1" is the default, not "configset-1". It is an unfortunate kitchen-sink, with many tests using it. I'd rather see tests use one of several basic / standard configs without any quirks and then if needed modify it at runtime using config edit API or another approach on the fly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I've backed out the change to this class... I think moving this class to using the kitchen sink collection1 is better than just randomly using configset-2, which was meant for only the TestConfigSets class, but I'd rather get this PR in! I do agree we need to deal with the kitchen-sink issue!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked into the history of configset2 when I wrote my comment. I see it as a general addition for something simple. It has a bad name! Other tests now use it too. I didn't see it as a configset that was designed fundamentally and only for TestConfigSets. Maybe I overlooked something... why do you think it's only suitable for that test?
| Path.of(instance.getHomeDir(), "solr.xml"), | ||
| StandardCopyOption.REPLACE_EXISTING); | ||
| Properties nodeProperties = new Properties(); | ||
| nodeProperties.setProperty("solr.data.dir", instance.getDataDir()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess generally you have identified that setting solr.data.dir isn't necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah... I ran the test before and after the cahnge and everythign was green. Then I started looking for other tests that had solr.data.dir and did the same thing...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I at least checked where SolrInstance is used, data dir is the default so, indeed, at least where SolrInstance is used (like here), we don't need to relay it to "solr.data.dir".
|
Okay, we got to green! I'd love a +1. I will wait till I figure out what is causing builds in main to fail on DistributedDebugComponentTest first however. |
|
@dsmiley with the various changes I've made today, thoughts on being able to merge this? |
dsmiley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this should be merged until you've validated these tests work with SSL mode, or say generally a higher tests multiplier. Probably requires #4008
Can you please remove
| h.getCoreContainer().waitForLoadingCoresToFinish(30000); |
waitForLoadingCoresToFinish that seems pointless?
| @@ -2259,12 +2258,6 @@ public static void copyMinConf(Path dstRoot, String propertiesContent, String so | |||
| subHome.resolve("solrconfig.snippet.randomindexconfig.xml")); | |||
| } | |||
|
|
|||
| // Just copies the file indicated to the tmp home directory naming it "solr.xml" | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hate this method; thanks for removing it.
| Files.copy(Path.of(src_dir, "schema-binaryfield.xml"), confDir.resolve("schema.xml")); | ||
| Files.copy(Path.of(src_dir, "solrconfig-basic.xml"), confDir.resolve("solrconfig.xml")); | ||
| // Copy the custom schema for binary field tests | ||
| String sourceConfDir = TEST_HOME() + "/collection1/conf"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(okay to defer this; problem pre-existed)
If you look carefully at what's happening here (was before), this is sad. TEST_HOME() returns a Path, which we toString via string concatenation to a String representing a path, and then a line below we create a Path via Path.of. Obviously we should instead be using the resolve method on Path. The tell-tale sign of the problem is the usage of Path.of which we should ideally use sparingly (when we truly have a String input that can't be a Path).
CC @mlbiscoc
Description
Noticed some places where we had setup logic that wasn't needed.
Solution
Pruned it back!
Tests
Re ran tests