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-16801: Set previous context class loader after loading plugin #1645

Merged
merged 5 commits into from May 18, 2023

Conversation

thomaswoeckinger
Copy link
Contributor

@thomaswoeckinger thomaswoeckinger commented May 16, 2023

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

Description

Due to SOLR-16240 context class loader was set before loading CoreContainer.

As the context class loader is not unset when loading is finished it is currently impossible to use
EmbeddedSolrServer within Tomcat and JSF, as it the whole class loading during servlet init process.

Solution

Set context class loader to original context class loader after plugin loading.

Tests

Plugin loading tests are already provided.

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)
  • 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

@thomaswoeckinger thomaswoeckinger changed the title SOLR-164801: Set previous context class loader after loading plugin SOLR-16801: Set previous context class loader after loading plugin May 16, 2023
@thomaswoeckinger
Copy link
Contributor Author

@HoustonPutman plz review

Copy link
Contributor

@HoustonPutman HoustonPutman left a comment

Choose a reason for hiding this comment

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

So there might be plugins that aren't authentication that might need the Solr classloader on initialization. Is there are issue doing this try {} finally {} in load() instead of in initializeAuthentication()?

We could also just do this try {} finally {} logic in EmbeddedSolrServer. load(CoreContainer cc). That way it works for embedded use cases. I'm not sure if theres any gain to solving this outside of the embedded use case.

@thomaswoeckinger
Copy link
Contributor Author

So there might be plugins that aren't authentication that might need the Solr classloader on initialization. Is there are issue doing this try {} finally {} in load() instead of in initializeAuthentication()?

No issue, it simply has to be decided if the usage of a custom context class loader should be as isolated as possible or not.
Both ways will work.

We could also just do this try {} finally {} logic in EmbeddedSolrServer. load(CoreContainer cc). That way it works for embedded use cases. I'm not sure if theres any gain to solving this outside of the embedded use case.

Sure, but i think it would be better to have a defined scope where this context class loader should/must be active.

At the end someone has to decide it, personally i would only use a different context class loader for the parts where it is required.

@HoustonPutman
Copy link
Contributor

Ok I moved the logic to surround the entire load method.

For future PRs, please make them against main, not any other branch. I'm going to edit this PR to make it work though.

@HoustonPutman
Copy link
Contributor

Do you mind if I force push to your branch_9x, I'm going to push the current main with these two commits cherry-picked on top? You will need to reset (delete and recreate) the branch after this PR gets merged, but at least we get to keep the PR history...

// Set the thread's contextClassLoader for any plugins that are loaded via Modules or Packages
// and have dependencies that use the thread's contextClassLoader
Thread.currentThread().setContextClassLoader(loader.getClassLoader());
loadInternal();
Copy link

Choose a reason for hiding this comment

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

7% of developers fix this issue

THREAD_SAFETY_VIOLATION: Unprotected write. Non-private method CoreContainer.load() indirectly writes to field noggit.JSONParser.devNull.buf outside of synchronization.
Reporting because another access to the same memory occurs on a background thread, although this access may not.


ℹ️ Expand to see all @sonatype-lift commands

You can reply with the following commands. For example, reply with @sonatype-lift ignoreall to leave out all findings.

Command Usage
@sonatype-lift ignore Leave out the above finding from this PR
@sonatype-lift ignoreall Leave out all the existing findings from this PR
@sonatype-lift exclude <file|issue|path|tool> Exclude specified file|issue|path|tool from Lift findings by updating your config.toml file

Note: When talking to LiftBot, you need to refresh the page to see its response.
Click here to add LiftBot to another repo.

@thomaswoeckinger
Copy link
Contributor Author

Do you mind if I force push to your branch_9x, I'm going to push the current main with these two commits cherry-picked on top? You will need to reset (delete and recreate) the branch after this PR gets merged, but at least we get to keep the PR history...

No problem, just force push

@thomaswoeckinger
Copy link
Contributor Author

Ok I moved the logic to surround the entire load method.

For future PRs, please make them against main, not any other branch. I'm going to edit this PR to make it work though.

👌

@HoustonPutman
Copy link
Contributor

Ok, it looks like I can't force push to your repo. Could you force push main:branch_9x? I think I can cherry pick the commits after that.

@thomaswoeckinger
Copy link
Contributor Author

thomaswoeckinger commented May 18, 2023

Ok, it looks like I can't force push to your repo. Could you force push main:branch_9x? I think I can cherry pick the commits after that.

Done, i pushed branch_9x over main, they are equal now

@HoustonPutman
Copy link
Contributor

Sorry, its the other way around, you need to push main on top of your branch_9x.

@thomaswoeckinger
Copy link
Contributor Author

thomaswoeckinger commented May 18, 2023

Sorry, its the other way around, you need to push main on top of your branch_9x.

Ok, should i cherry pick the changes already, from the local branch_9x?

@thomaswoeckinger
Copy link
Contributor Author

Cherry pick is already done

@HoustonPutman HoustonPutman changed the base branch from branch_9x to main May 18, 2023 21:07
@HoustonPutman
Copy link
Contributor

Tada! Thanks for the help there.

I think this is good to go. Will ask for another review and add a changelog entry.

@thomaswoeckinger
Copy link
Contributor Author

Tada! Thanks for the help there.

I think this is good to go. Will ask for another review and add a changelog entry.

Okay, thx for your fast response, if any further actions are required just let me know.

@HoustonPutman HoustonPutman merged commit 0a6a114 into apache:main May 18, 2023
2 of 3 checks passed
HoustonPutman pushed a commit that referenced this pull request May 18, 2023
…oreContainer (#1645)

Co-authored-by: Thomas Wöckinger <two@silbergrau.com>
Co-authored-by: Houston Putman <houston@apache.org>
(cherry picked from commit 0a6a114)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants