-
Notifications
You must be signed in to change notification settings - Fork 193
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
@GrabConfig(systemClassLoader = true) Causing No suitable ClassLoader found for grab Exception #779
Comments
If you are running this as a Groovy Script, then compilation is deferred until When launching from Eclipse as a Groovy Script, a process typically runs a command line like:
|
Assuming the code I listed above is in the file GrapesFailing.groovy When I run: Eclipse failing run configuration information: VM arguments: Please let me know if there is any further info I can provide to help track down the issue. |
So what command line does the bat file end up running and have you tried the command line that Eclipse uses to launch from a command prompt? |
This is what command line is actually called after digging into
The command line generate by eclipse that fails:
In order to make the eclipse command line work I had to make the following changes. I also had to modify |
By setting if (systemClassLoader) loader = ClassLoader.getSystemClassLoader(); This prevents the use of the class loader from the source unit on this line of basicArgs.put("classLoader", loader != null ? loader : sourceUnit.getClassLoader()); Within public grab(Map args, Map... dependencies) {
ClassLoader loader = null
grabRecordsForCurrDependencies.clear()
try {
// identify the target classloader early, so we fail before checking repositories
loader = chooseClassLoader(
classLoader:args.remove('classLoader'),
refObject:args.remove('refObject'),
calleeDepth:args.calleeDepth?:DEFAULT_DEPTH,
)
...
public def chooseClassLoader(Map args) {
def loader = args.classLoader
if (!isValidTargetClassLoader(loader)) {
loader = (args.refObject?.class
?:ReflectionUtils.getCallingClass(args.calleeDepth?:1)
)?.classLoader
while (loader && !isValidTargetClassLoader(loader)) {
loader = loader.parent
}
if (!isValidTargetClassLoader(loader)) {
throw new RuntimeException("No suitable ClassLoader found for grab")
}
private boolean isValidTargetClassLoaderClass(Class loaderClass) {
return (loaderClass != null) &&
(
(loaderClass.name == 'groovy.lang.GroovyClassLoader') ||
(loaderClass.name == 'org.codehaus.groovy.tools.RootLoader') ||
isValidTargetClassLoaderClass(loaderClass.superclass)
)
}
The class loader returned by |
So, if I add this to the JVM arguments, the system class loader is accepted and the script runs: |
Good Morning Eric, Thank you for the thorough explanation and correction of the root issue. I have verified my test code works on the latest version of the plugin for eclipse 2018-09. The only remaining issue is Eclipse still records an error in the problems tab when Thanks, |
Ahh, yes. If you open your script in the editor, GDT will try and process it through most compiler phases to give better content assist support. If you add a script filter to your project or workspace, the compiler will not try and produce a class file, which should prevent adding errors to the Problems view. |
I attempted that suggestion and unfortunately it did not resolve the issue. The error is still being flagged in the class. Additionally, I use grapes in drivers for programs where the driver resides in the same package as the class being run. I don't think I would want to wait till run-time for the classes to be compiled. Are there any other options you know of to exclude checking for this specific error? |
Actually I found a solution that works for us. We only use grapes when running code outside of eclipse, so adding the argument Thanks again for all of your help! |
If you want to mark some classes in a package as scripts and compile some others, you can alter the script pattern any way you wish. It need not exclude everything in a package -- like |
The following example code fails to execute due to the inclusion of @GrabConfig(systemClassLoader = true), which is required for the program to run in production.
I have tried running this using Groovy 2.4.7 on Eclipse Neon and on a clean install of Eclipse Neon running Groovy 2.4.13. I'm confused because it appears the line of code throwing the exception is commented out in the Groovy-Eclipse source code, but perhaps I'm looking in the wrong area. Please let me know if there is any more info I can provide to help solve this issue!
update: I also verified this does not work running the latest version of Eclipse 2018-09 running the 2.4.15 compiler.
Source Code referenced: https://github.com/groovy/groovy-eclipse/blame/337f7d8fe709d0c7d469202425153b6ed1bbfd0c/base/org.codehaus.groovy24/src/groovy/grape/GrapeIvy.groovy#L181
Code:
Stack Trace:
The text was updated successfully, but these errors were encountered: