-
-
Notifications
You must be signed in to change notification settings - Fork 290
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
Add new constructors to scan only selected files / directories / classloaders #77
Comments
I am currently using this code to simulate the behaviour of the constructors accepting ClassLoaders:
It works but using reflection for that task is ugly. |
Yeah, you don't want to do the reflection thing :-) You can already limit scanning to specific files/dirs by joining the file paths into a standard-format path string using I just added a couple of methods for adding a ClassLoader, or replacing all ClassLoaders: This is a niche use case though, so I'm curious, what are you doing that requires this? Are your ClassLoaders not visible anywhere in the current thread (i.e. are you doing some sort of dynamic classloading that does not use the current thread's classloader)? |
Please test the git head revision, and let me know if this solves your problem. If so, this will be in the next release. |
Much better but I still need to clear "java.class.path" before starting the scan (compare the outputs below). I think it's because of ClasspathFinder line 151. It should be skipped if FastClasspathScanner#overrideClassLoaders was called. Another improvement would be to return the FastClasspathScanner in the new methods to allow chaining of calls. My use case is a (simple) plugin system where all plugin archives have to be separated to avoid dependency conflicts. Log with System.clearProperty("java.class.path"):
Log without System.clearProperty("java.class.path"):
|
Hi, I fixed both issues (the methods now support chaining, and This should work for you, but please comment and let me know. Feel free to re-open or file another bug if you find other issues. Thanks for the report! |
I also just added |
I use this code to test:
I think, it doesn't work because you never set that I don't think I can re-open an issue I didn't close: Issue on github |
@jrb0001 Sorry, I don't know how I missed that, I did intend to add that line! Thanks for going to the trouble of figuring out what was wrong. I didn't know that issue creators could not re-open issues at will, that seems like it would cause problems more often than it solves. Presumably you can close this if it's fixed though -- please test one more time, hopefully now this works for you. |
Fixed! Thank you for this really useful library. |
Great, you're welcome, thanks for the suggestions and testing! I might wait a bit to push out a new release, in case other issues are reported, to reduce version churn, but this will be in the next release (2.0.4). |
Released in version 2.0.4. |
These constructors would be useful to scan only a few jars / directories in case you do not want to modify nor scan the current classpath (eg in a plugin system):
Only the given classloaders / files / directories should be scanned. Parent classloaders, all other classloaders and "java.class.path" should be ignored.
The text was updated successfully, but these errors were encountered: