I inherited a Grails app that, on a fresh checkout, I can't get to run. Of course the people that originally worked on this project are long gone. I have other Grails projects that run correctly (out of the box) so I know it's not my config.
setup info:
> cat application.properties
#Grails Metadata file
#Tue Jul 09 16:31:14 IST 2013
app.grails.version=2.1.1
app.name=myapp
app.version=0.1
> grails -version
Grails version: 2.1.1
echo $GROOVY_HOME
/cygdrive/c/Users/myuser/.gvm/groovy/current
> echo $GRAILS_HOME
/cygdrive/c/Users/myuser/.gvm/grails/2.1.1
Now the stacktrace:
grails run-app --stacktrace
| Configuring classpath.
Environment set to development
| Configuring classpath.....
| Error Error executing script RunApp: taskdef class org.codehaus.groovy.grails.compiler.GrailsCompiler cannot be found
using the classloader AntClassLoader[] (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.)
java.lang.ClassNotFoundException: org.codehaus.groovy.grails.compiler.GrailsCompiler
at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1361)
at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1311)
at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064)
at org.apache.tools.ant.taskdefs.Definer.addDefinition(Definer.java:594)
at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:239)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.codehaus.gant.GantBuilder.invokeMethod(GantBuilder.java:99)
at _GrailsCompile_groovy.run(_GrailsCompile_groovy:32)
at _GrailsCompile_groovy$run.call(Unknown Source)
at _GrailsPackage_groovy$run.call(Unknown Source)
at org.codehaus.gant.IncludeTargets.leftShift(IncludeTargets.groovy:59)
at org.codehaus.gant.IncludeTargets$leftShift.call(Unknown Source)
at _GrailsPackage_groovy.run(_GrailsPackage_groovy:38)
at _GrailsPackage_groovy$run.call(Unknown Source)
at _GrailsSettings_groovy$run.call(Unknown Source)
at org.codehaus.gant.IncludeTargets.leftShift(IncludeTargets.groovy:59)
at org.codehaus.gant.IncludeTargets$leftShift.call(Unknown Source)
at _GrailsPlugins_groovy.run(_GrailsPlugins_groovy:33)
at _GrailsPlugins_groovy$run.call(Unknown Source)
at _GrailsRun_groovy$run.call(Unknown Source)
at org.codehaus.gant.IncludeTargets.leftShift(IncludeTargets.groovy:59)
at org.codehaus.gant.IncludeTargets$leftShift.call(Unknown Source)
at _GrailsRun_groovy.run(_GrailsRun_groovy:31)
at _GrailsRun_groovy$run.call(Unknown Source)
at org.codehaus.gant.IncludeTargets.leftShift(IncludeTargets.groovy:59)
at org.codehaus.gant.IncludeTargets$leftShift.call(Unknown Source)
at RunApp.run(RunApp.groovy:25)
at RunApp$run.call(Unknown Source)
at gant.Gant.prepareTargets(Gant.groovy:607)
at com.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1231)
| Error Error executing script RunApp: taskdef class org.codehaus.groovy.grails.compiler.GrailsCompiler cannot be found
using the classloader AntClassLoader[]
Nothing I seem to do gets past this or changes it. Anyone have any ideas how to fix this?
run grails upgrade - Still not sure why this works but I've had to do it on occasion with a fresh checkout.
check dependencies:
grails dependency-report
Check the output for multiple versions of Groovy or Spring in the build configuration.
http://grails.org/doc/latest/ref/Command%20Line/dependency-report.html
use exclusions or specific dependencies in BuildConfig.groovy to use certain version.
make sure to check different configurations since some dependencies might be just in test configuration, and a different version in compile or build. That might sometimes be a problem with dependencies.
references:
http://grails.1312388.n4.nabble.com/Upgrading-a-project-from-1-3-6-to-1-4-0-M1-td3603895.html
Another check:
Make sure you don't have a ~/.ant/lib directory. I have seen that cause strange problems.
rename it if it exists:
mv ~/.ant/lib{,.old}
Try upgrading directly to Grails 2.3.11 since 2.1.x or 2.2.x Grails branches aren't maintained any more. Take a look at the release notes from grails.org website (https://grails.org/Releases) and grails reference manual for upgrade instructions.
You should take a look at these instructions:
Upgrading from 2.1.x to 2.2.x:
http://grails.org/doc/2.2.x/guide/upgradingFromPreviousVersionsOfGrails.html
Upgrading from 2.2.x to 2.3.x:
http://grails.org/doc/2.3.x/guide/upgradingFromPreviousVersionsOfGrails.html
Read all release notes after the version you are upgrading from:
https://grails.org/Releases
Some extra upgrade tips:
remove all plugin dependencies from application.properties files and move them to BuildConfig.groovy
compare grails-app/conf/* and web-app/WEB-INF/* files of an empty application (of a new version) to your application with a diff tool like Meld , WinMerge, etc.
if you have a templates directory , compare that to an empty application (of a new new version) that has templates installed (grails install-templates).
I had a similar problem, and #Beatty's answer didn't work, because that also would give me an error. Following some possible solutions I found here, I fixed this by deleting the target folder in my app's folder
rm -rf target/*
and then, running again grails compile
Hope this helps
Related
I have two Jenkins both on the same version 2.289.3. One has this plugin working fine (plugin version 1.54) but the other is failing with the error in the below error code. It's failing on the plugin extensions
io.jenkins.plugins.casc.ConfiguratorException: No configurator for the following root elements jobs
at io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:734)
at io.jenkins.plugins.casc.ConfigurationAsCode.checkWith(ConfigurationAsCode.java:776)
at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:761)
at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:637)
at io.jenkins.plugins.casc.ConfigurationAsCode.configure(ConfigurationAsCode.java:306)
at io.jenkins.plugins.casc.ConfigurationAsCode.init(ConfigurationAsCode.java:298)
Caused: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
These two Jenkins run off of different config repositories but the major files are all the same. I removed the plugin from the startup plugins.txt file and tried installing it on a running Jenkins but that results in the same problem when I then restart Jenkins (below image and error)
org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException
I've also tried copying the plugins from other repositories that have no problems but here it just keeps failing. Any advice on what the problem might be would be great
The solution to my problem was that I was missing another plugin. The plugin in question was job-dsl - specifically version 1.74 of this plugin. I found some of the later version also caused problems so had to pin it to 1.74
I'm trying to install Jenkins on win 10.
all the plugins failed to install on the startup process and even after that for jenkins GUI.
i'm running with jenkins 2.264,jdk-8u271-windows-x64 and windows 10 pro.
please advise what am I doing worng.
this is one of my error messages ->
most of the errors look the same. (Java issue)
java.io.IOException: Failed to load: Build Timeout (1.20)
- Plugin is missing: token-macro (1.5.1)
at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:951)
at hudson.PluginManager$2$1$1.run(PluginManager.java:551)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
at jenkins.model.Jenkins$5.runTask(Jenkins.java:1129)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:68)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2020-12-24 18:52:29.987+0000 [id=46] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed Loading plugin ECharts API Plugin v4.9.0-2 (echarts-api)
java.io.IOException: Failed to load: ECharts API Plugin (4.9.0-2)
What you have posted is an incomplete pair of error segments (they should start w/timestamp). Nevertheless, not sure how you installed the plugins, but you appear to be missing some key dependencies.
Failed to load: Build Timeout (1.20) - Plugin is missing: token-macro (1.5.1)
token-macro is a dependency on Build Timeout, and appears not to installed.
Failed to load: ECharts API Plugin (4.9.0-2)
This error is incomplete, but I would suspect is also missing a dependency. You can see what is installed on the ${JENKINS_URL}/systemInfo page, "Plugins" section. Not sure what you will see on the ${JENKINS_URL}/pluginManager/installed, but I suspect many plugins will be greyed out. It should explain why (ie: missing).
You would have to explain how you installed what you did to guess how got are missed. Rarely plugins simply declare as "optional" what should be declared as required, but goes undetected since almost everyone always installs the dependency.
Usually, they all point to a single missing plugin or a chain up from one. Check the logs and trace. Get all the pairs Failed to load: x - Plugin is missing: y. Install the ones said to be missing. Failing that, stop Jenkins, delete the /plugins directory and install them from scratch again. If the hpi/jpi package is corrupted, you may need to stop Jenkins, delete the package and the exploded directory inside plugins.
You may also find this response useful, as well as the Jenkins Book Managing Plugins and the new Plugin Installation Manager Tool for Jenkins
Everything worked before in this project. I updated Grails from 3.3.1 to 3.3.2 and it still worked. I also updated Gradle and now it does not work.
Both gradlew bootRun and gradlew war work and the war file deploys to Tomcat and works fine.
To generate pdf documents I have these dependencies:
compile "org.xhtmlrenderer:flying-saucer-core:9.1.9"
compile "org.xhtmlrenderer:flying-saucer-pdf:9.1.9"
compile "com.lowagie:itext:4.2.1"
After cleaning I run 'grails compile'and get this:
General error during class generation: java.lang.NoClassDefFoundError: Unable to load class org.xhtmlrenderer.pdf.ITextRenderer due to missing dependency Lcom/lowagie/text/Document;
java.lang.RuntimeException: java.lang.NoClassDefFoundError: Unable to load class org.xhtmlrenderer.pdf.ITextRenderer due to missing dependency Lcom/lowagie/text/Document;
at org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToCompilationError(CompilationUnit.java:1101)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1079)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:537)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:175)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:56)
at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerRunnable.run(AbstractDaemonCompiler.java:87)
at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:36)
at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:46)
at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
With stacktrace:
java.util.concurrent.ExecutionException: org.gradle.tooling.BuildException: Could not execute build using Gradle installation '/home/chris/.sdkman/candidates/gradle/current'.
at java_util_concurrent_Future$get.call(Unknown Source)
at run-app.run(run-app.groovy:89)
When I did this pdf thing the grails rendering plugin would not work. So I created a small proof of concept application using the Flying Saucer libraries directly. It uses the same dependencies as given above and the code is the same. This small Grails application still works with 'grails compile' and 'grails run-app'
In Idea I get exactly the same problems even though Idea is set to use the application's Gradle wrapper.
Nowhere do I import or use com.lowagie.text.Document - the class about which the errors complain. And the thing works perfectly when using gradlew and it worked before whichever way I ran or compiled the application. And that class is in the itext:4.2.1 dependency. I downloaded the jar and looked.
org.xhtmlrenderer.pdf.ITextRenderer is imported and used. Idea has no problems with it. Idea usually warns one if one tries to import or use a class not on the classpath.
I tried reverting back to previous versions of Gradle, but no luck.
This is not a show stopper as gradlew still works. But what the heck is going on? Any ideas?
We are on grails-3.3.2. We faced similar issues. We tried running few commands in the following sequence and it then worked for us. We didn't get any compilation issues later on.
gradlew --stop //To stop Daemon threads
gradlew clean //gradle clean
grails clean // this will now clean entirely
grails compile
Now compile should not have any issues.
Has anyone successfully updated the log4j jar file for jenkins to get the udeploy plugin working by following the instructions provided on their site http://wiki.urbancode.com/uDeploy/Repositories, seen below?
Note: Jenkins often uses an older log4j file then our plugin needs. You may need to replace it. See below for instructions:
1. Unpackage the jenkins.war
2. Open /web-inf/lib in the unpacked .war's directory to determine the name of Jenkin's log4j.jar
3. Navigate to your uDeploy server's %serverLocation%/lib directory and copy our log4j.jar to Jenkin's /web-inf/lib/ directory, overwriting the existing log4j with uDeploy's (rename it to match Jenkin's)
On standalone instances of Jenkins (not the Tomcat app), Jenkins keeps a hash of all of it's files and will throw an error when starting Jenkins due to a mismatched hash after modifying the log4j file. The only solution is to remove the values in the file that tracks the hashes."
I unpackaged the war file, deleted the log4j jar (1.2.9) found under WEB-INF/lib/, added the newest log4j jar (1.2.17), renamed it to 1.2.9, then removed the SHA1-Digest: line (the hash) for log4j 1.2.9 found in the manifest under META-INF/ all which seems to agree with the above instructions. Deploying the war (service jenkins start) results in the following error, complaining that the SHA1 signature isn't there in the manifest:
Starting Jenkins Exception in thread "main" java.lang.SecurityException: invalid SHA1 signature file digest for WEB-INF/lib/log4j-1.2.9.jar
at sun.security.util.SignatureFileVerifier.verifySection(SignatureFileVerifier.java:457)
at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:250)
at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:193)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:262)
at java.util.jar.JarVerifier.update(JarVerifier.java:216)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:341)
at java.util.jar.JarFile.getInputStream(JarFile.java:406)
at sun.misc.URLClassPath$JarLoader$2.getInputStream(URLClassPath.java:752)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:436)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:476)
[FAILED]
What am I missing? I thought I followed the directions correctly, and evidently enough people have had this problem given that uDeploy added a special note to their wiki page about it. Any help/suggestions/ideas would be highly appreciated.
Jenkins is version 1.525.
If anyone is still interested in solution, I didn't remove digests. Just deleted log4j-1.2.9.jar and added log4j-1.2.17.jar (without renaming), that's all I did. An it worked brilliantly. Jenkins version 1.542.
Why did you rename it to 1.2.9? It will probably work as named as 1.2.17. It's a signed jar, and renaming it may be why it broke.
If jenkins is running on tomcat on linux, you are probably faster just logging into the box to the webapps directory and altering the expanding war there rather than repacking the jenkins war.
Follow the following steps to change the log4j version and solve the stated uDeploy problem :-
Stop Jenkins
Go to the installation directory of Jenkins
Navigate to .jenkins\war\WEB-INF\lib [On a windows system]
Delete log4j-1.2.9.jar and add log4j-1.2.17.jar (without renaming)
Restart Jenkins
It is not necessary to follow all the steps given as a solution by IBM :-
https://developer.ibm.com/urbancode/plugin/jenkins-ibmucd/
At this point, just use the new version of the Jenkins plugin. The incompatibility was removed.
I am migrating my application from Grails 2.1 to 2.3. I am getting lot of errors after migration - I want some sample applications with Grails 2.3 and Spring integration.
I did some HelloWorld sample applications, and those are working fine. But even I apply same thing in my application, even some where it is giving error. Because my application is very big(100mb) and i am using lot of integration with Spring, Hibernate, and lot of Grails plugins.
I did not find any code level document for "Migrate from Grails 2.1 to Grails 2.3" like that. I am not able to find any sample applications from Grails or online.
Grails official documentation, all about providing Grails META information.
In my main.gsp 229 line:
<g:include controller="filter" action="tree"/>
Caused by: org.codehaus.groovy.grails.web.pages.exceptions.GroovyPagesException: Error processing GroovyPageView: Error executing tag <g:include>: Unable to execute include: Request processing failed; nested exception is org.codehaus.groovy.grails.exceptions.GrailsRuntimeException: java.lang.IllegalStateException: Cannot reset buffer after response has been committed
at org.codehaus.groovy.grails.web.servlet.view.GroovyPageView.createGroovyPageException(GroovyPageView.java:205)
at org.codehaus.groovy.grails.web.servlet.view.GroovyPageView.handleException(GroovyPageView.java:182)
at org.codehaus.groovy.grails.web.servlet.view.GroovyPageView.renderWithTemplateEngine(GroovyPageView.java:153)
at org.codehaus.groovy.grails.web.servlet.view.GroovyPageView.renderMergedOutputModel(GroovyPageView.java:84)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:264)
at org.codehaus.groovy.grails.web.sitemesh.SpringMVCViewDecorator.render(SpringMVCViewDecorator.java:67)
... 51 more
Caused by: org.codehaus.groovy.grails.web.taglib.exceptions.GrailsTagException: Error executing tag <g:include>: Unable to execute include: Request processing failed; nested exception is org.codehaus.groovy.grails.exceptions.GrailsRuntimeException: java.lang.IllegalStateException: Cannot reset buffer after response has been committed
at org.codehaus.groovy.grails.web.pages.GroovyPage.throwRootCause(GroovyPage.java:531)
at org.codehaus.groovy.grails.web.pages.GroovyPage.invokeTag(GroovyPage.java:475)
at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1085)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:989)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:1110)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:909)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
at mycompany_dev_testuserdev_ws3_myapp_grails_app_views_layouts_main_gsp$_run_closure2.doCall(main.gsp:229)
Compare your Config.groovy and BuildConfig.groovy files to the defaults of an empty new Grails 2.3 application.
The most notable change is that plugin dependencies should not be described in application.properties any more. You should also make sure that you are using the correct version of Grails Tomcat, Hibernate and Scaffolding plugins. Tomcat & Hibernate plugin versions no more are the same as the Grails release version. Scaffolding features have been extracted to separate plugin in Grails 2.3 .
Make also sure you use correct scope for plugins (build for tomcat, runtime for hibernate).
It's also recommended to start using the new maven based (uses aether library which is part of maven) dependency resolution. This is done with the setting grails.project.dependency.resolver = "maven" in BuildConfig.groovy . I ran in to strange classloading problems with the old ivy based resolver in Grails 2.3 .
I hope this helps.
It very simple to migrate Grails 2.3 -(My case , i am using ivy, pom in Grails 2.1.4)
Do a sample project and run - confirm it working. Keep it as reference.
In your project, move all the jars and plugins from pom to BuildConfig, there is no new formats, as usual that you know already. (Note: Don't miss even one jar or plugin, It will take days to realize that, i did same mistake costs 1 and half day.)
And, copy jars and plugins configurations from SampleProject -> BuildConfig to your project BuildConfig, If you have same jars in you app also, check and remove old versions and kept the latest one.
After copy this in BuildConfig
forkConfig = [maxMemory: 1024, minMemory: 64, debug: false, maxPerm: 256]
grails.project.fork = [
test: forkConfig, // configure settings for the test-app JVM
run: forkConfig, // configure settings for the run-app JVM
war: forkConfig, // configure settings for the run-war JVM
console: forkConfig // configure settings for the Swing console JVM
]
grails.project.dependency.resolver = "maven" // or ivy
grails.project.dependency.resolution = {
run Grails upgrade
run Grails run-app