Skip to content
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

SOLR-XXXXX: Support different filesystem implementations with EmbeddedSolrServer #3146

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

AndreyBozhko
Copy link
Contributor

@AndreyBozhko AndreyBozhko commented Jan 29, 2025

https://issues.apache.org/jira/browse/SOLR-XXXXX

Description

EmbeddedSolrServer has a public constructor EmbeddedSolrServer(Path solrHome, String defaultCoreName) - which suggests that any Path implementation is acceptable (e.g., ZipPath, S3Path, and not just UnixPath/WindowsPath).

Solution

Updated ManagedIndexSchemaFactory code that deals with schema paths to be more idiomatic, and correctly handle Path instances associated with non-default file systems.

Tests

Added a test for instantiating EmbeddedSolrServer using a ZipPath instance.

Checklist

Please review the following and check all that apply:

  • I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
  • I have created a Jira issue and added the issue ID to my pull request title.
  • I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
  • I have developed this patch against the main branch.
  • I have run ./gradlew check.
  • I have added tests for my changes.
  • I have added documentation for the Reference Guide

"""
Test only works without Security Manager due to SecurityConfHandlerLocal
missing permission to read /1/2/3/4/security.json file""",
System.getSecurityManager() == null);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make the test work regardless of the security manager, this line

securityJsonPath = Paths.get(coreContainer.getSolrHome()).resolve("security.json");
needs to be updated to handle Path in a more idiomatic way.

However, that requires updating CoreContainer#getSolrHome to return a Path instead of a String - so it looks like a much bigger change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CoreContainer.solrHome is a Path so hopefully it won't be too huge to switch it's getter to use Path.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I think I will keep this PR as draft for now, and work on updating CoreContainer#getSolrHome to return Path first. Is there an existing JIRA for that?

@@ -148,12 +147,11 @@ public String lookupZKManagedSchemaPath() {
*/
public Path lookupLocalManagedSchemaPath() {
final Path legacyManagedSchemaPath =
Paths.get(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should try to remove usages of Paths.get generally, I remember it having some wonky behaviour in the past. Happy to see this coming in.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely; same with Path.of. Ultimately we should ForbiddenApi check this so that it's rare to call this except for a few authorized places.

Copy link
Contributor

@dsmiley dsmiley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really about SOLR-17548 / SOLR-16903 / SOLR-8282 / SOLR-17548. I don't think we need separate JIRAs for separate File->Path or String->Path matters, but separate PRs is great. Not only do we need to convert File -> Path, but we need to change most String based paths to Path. Perhaps PR, by PR we focus on one particular String. I don't think this PR is really about EmbeddedSolrServer (you put that in the title).

@@ -148,12 +147,11 @@ public String lookupZKManagedSchemaPath() {
*/
public Path lookupLocalManagedSchemaPath() {
final Path legacyManagedSchemaPath =
Paths.get(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely; same with Path.of. Ultimately we should ForbiddenApi check this so that it's rare to call this except for a few authorized places.

"""
Test only works without Security Manager due to SecurityConfHandlerLocal
missing permission to read /1/2/3/4/security.json file""",
System.getSecurityManager() == null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CoreContainer.solrHome is a Path so hopefully it won't be too huge to switch it's getter to use Path.

@AndreyBozhko
Copy link
Contributor Author

Thanks - I just opened SOLR-17640 before reading your comment. Do you suggest this should go under SOLR-16903 instead? Or would you prefer to see a more comprehensive refactoring for Paths#get usage in the codebase?

@dsmiley
Copy link
Contributor

dsmiley commented Jan 30, 2025

Probably need to wait for @mlbiscoc in #2924 which is touching lots of stuff. Then pick a particular String based API endpoint and convert it in an isolated PR relating to that one method or class (if there are multiple). I think it's easier to review like this rather than touching everything.

Copy link
Contributor

@epugh epugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really interesting experiment ;-). ZipFS kind of neat!

@@ -34,6 +34,8 @@ Improvements

* SOLR-17516: `LBHttp2SolrClient` is now generic, adding support for `HttpJdkSolrClient`. (James Dyer)

* SOLR-XXXXX: Support different filesystem implementations with EmbeddedSolrServer (Andrey Bozhko)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DOn't we have a GH or GITHUB type name for a PR with no JIRA?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe he put this here as a TODO. We have quite a number of existing JIRAs to pick from for this theme :-).

@AndreyBozhko AndreyBozhko marked this pull request as draft January 31, 2025 17:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants