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
fixes #3399: Access to configuration in context class loader factory #3400
Conversation
ivakegg
commented
May 12, 2023
- Added a context class loader environment that supplies configuration
- Updated class loader util to set the configuration on the factory
…ctory * Added a context class loader environment that supplies configuration * Updated class loader util to set the configuration on the factory
* Updated default context class loader factory to use environment
Overall, this looks like a good idea, but I'm still working through reviewing the details of the change. |
* Improve javadoc comments on environment interface * Remove unneeded AccumuloConfigurationAdaptor - instead, keep the DefaultContextClassLoaderFactory constructed directly using the internal configuration, rather than load it through reflection using the no-arg constructor. We don't want users configuring this class manually, so it should not have a no-arg constructor. As the javadoc states, it is for internal use only. * Use a lambda for passing the service configuration rather than an anonymous inner class (less code, same effect)
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 this PR can be much more minimal. I have provided my code review suggestions to minimize the changes for this in ivakegg#5
core/src/main/java/org/apache/accumulo/core/classloader/ClassLoaderUtil.java
Outdated
Show resolved
Hide resolved
core/src/main/java/org/apache/accumulo/core/classloader/ClassLoaderUtil.java
Outdated
Show resolved
Hide resolved
core/src/main/java/org/apache/accumulo/core/classloader/DefaultContextClassLoaderFactory.java
Outdated
Show resolved
Hide resolved
core/src/main/java/org/apache/accumulo/core/conf/AccumuloConfigurationAdapter.java
Outdated
Show resolved
Hide resolved
core/src/main/java/org/apache/accumulo/core/spi/common/ContextClassLoaderEnvironment.java
Show resolved
Hide resolved
core/src/main/java/org/apache/accumulo/core/spi/common/ContextClassLoaderFactory.java
Outdated
Show resolved
Hide resolved
I think of it as a generic pattern, not something specific to this use. If an API/SPI method takes 1 parameter and you later want to add another, then it would have to be overloaded. Overloading is not a great way to evolve methods, especially for plugins. If each plugin interface method uses a bit of indirection and only takes one parameter which is an interface that gives access to all of the actual parameters, it makes it much easier to evolve the inputs for the method. So I see this as a generic pattern that all SPI methods can follow. If they are all following same pattern, its nice to use the same names. |
Code review changes - Minimize changes for apache#3400
core/src/main/java/org/apache/accumulo/core/spi/common/ContextClassLoaderEnvironment.java
Outdated
Show resolved
Hide resolved
…ClassLoaderEnvironment.java Co-authored-by: Keith Turner <kturner@apache.org>