SpringSource Tool Suite problem - grails

I installed STS 2.6.1.SR1 + added groovy & grails extensions. The Grails installation is pointing to Grails1.4 (Preferences->Grails). However, I can not perform any grails-related actions, like creating a new project. After importing an existing grails project (which was created in command prompt), it even can not be compiled. An output is always the same:
java.lang.NoClassDefFoundError: org/codehaus/groovy/tools/RootLoader
Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.tools.RootLoader
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Exception in thread "main"
Have anyone faced something similar?
Alex.

1.4 was only released a few days ago and its structure is quite different from previous releases. STS doesn't support it yet but this is being worked on and it will soon.

Option 1 -> Upgrade STS
SpringSource Tool Suite 2.7.0.M2 has now been released and supports Grails 1.4. Release notes are here
Option 2 -> Workaround.
Full details are available on the Spring Source Issue Tracker but this workaround may help...
com.springsource.sts.grails.core.internal.model.DefaultGrailsInstall.getBootstrapClasspath doesn't look for groovy-all-x.jar in the location where Grails 1.4 keeps it.
Workaround for running Grails 1.4 apps in STS:
cd /opt/grails-1.4.0.BUILD-SNAPSHOT/lib
ln -s org.codehaus.groovy/groovy-all/jars/groovy-all-1.8.0.jar

It's not an elegant solution but FWIW, with a similar issue (wanting groovy 1.8 in grails 1.3.7) I've found in practice that swapping the grails-1.3.7/lib/groovy-all-1.7.8.jar with groovy-all-1.8.4.jar works -- except you have to call the 1.8.4 jar "groovy-all-1.7.8.jar".
Worked for my app (for dev/test until newer grails is available) but of course YMMV.

Related

How to fix Jenkins java.lang.IllegalStateException: An attempt to save the global configuration was made before it was loaded

I upgraded from jenkins 2.219 to 2.272 (latest version as of this writing) and now getting the stack trace below when Jenkins starts.
Jenkins docs says that this happens due to the Configuration as Code plugin and to set the jvm args as -Dio.jenkins.plugins.casc.ConfigurationAsCode.initialDelay=9000. The docs also say to increment the value until the error goes away but so far I'm at 480000 and still getting the error. I also don't see that I have the Configuration as Code plugin installed anyway.
How can this be fixed?
java.lang.IllegalStateException: An attempt to save the global configuration was made before it was loaded
at jenkins.model.Jenkins.save(Jenkins.java:3379)
at jenkins.model.Jenkins.saveQuietly(Jenkins.java:3398)
at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:2637)
at jenkins.model.Jenkins$16.run(Jenkins.java:3342)
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(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused: org.jvnet.hudson.reactor.ReactorException
at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282)
at jenkins.InitReactorRunner.run(InitReactorRunner.java:50)
at jenkins.model.Jenkins.executeReactor(Jenkins.java:1162)
at jenkins.model.Jenkins.<init>(Jenkins.java:962)
at hudson.model.Hudson.<init>(Hudson.java:85)
at hudson.model.Hudson.<init>(Hudson.java:81)
at hudson.WebAppMain$3.run(WebAppMain.java:295)
Caused: hudson.util.HudsonFailedToLoad
at hudson.WebAppMain$3.run(WebAppMain.java:312)
For anyone having this issue, yes downgrading to https://get.jenkins.io/war-stable/2.263.1/ first is required. Then restart the service, then upgrade all of your plugins, then try the LTS upgrade again, at least for me it worked just fine.
More details about the issue here:
https://www.jenkins.io/doc/upgrade-guide/2.204/
SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed
ConfigurationAsCode.init java.lang.IllegalStateException: An attempt
to save the global configuration was made before it was loaded If
you encounter this, you can tell the plugin to delay configuration for
an amount of time to give Jenkins time to load the global
configuration before the configuration is applied by the plugin.
To enable this set the
io.jenkins.plugins.casc.ConfigurationAsCode.initialDelay system
property to a number of milliseconds to delay the initialisation. The
required value will be dependant on aspects of your system (cpu/disk)
and configuration, and how it can be found is mostly a trial and
error. A suggestion would be to start with 5000 (5 Seconds) and then
increment by 2000 (2 seconds) until you no longer exhibit the issue
and finally add 1000 (1 second) for some extra safety. For example, to
delay the configuration by 9 seconds you would use something like the
following command java
-Dio.jenkins.plugins.casc.ConfigurationAsCode.initialDelay=9000 -jar jenkins.war. Exactly how and where you specify this option depends on
the installation method used to install Jenkins
However for me the workaround didnt work without first downgrading, upgrading all plugins, then finally upgrading the core again.
To avoid this issue beforehand when you actually have not installed the Casc plugin:
Update to https://github.com/jenkinsci/role-strategy-plugin/releases/tag/role-strategy-3.1 and you should be OK.
When jenkins is already in the faulty state:
download the hpi and drop the hpi file into JENKINS_HOME/plugins folder.
https://updates.jenkins.io/download/plugins/role-strategy/
(information taken from: https://github.com/jenkinsci/configuration-as-code-plugin/issues/1531)
I faced the same issue. I have downloaded the jenkins.war , the earlier version (2.263.1) from https://www.jenkins.io/download/ . Stopped the jenkins and replaced the war with my install directory(C:\Program Files\Jenkins). And started the jenkins.This works like a charm.
You can download the hpi and drop the hpi file into JENKINS_HOME/plugins folder. Usually the jenkins plugin directory will be under - /var/lib/jenkins/plugins/.
The link to get Role strategy hpi plugin - https://updates.jenkins.io/latest/role-strategy.hpi. And restart Jenkins using this command: systemctl restart jenkins.
My scenario was to upgrade the Jenkins to the latest version and then restore the data in it to work like it was working before.
While upgrading from Jenkins v2.263 to v2.303, I had the same error. The only thing which worked for me was to upgrade my global plugin i.e Role-based authorization strategy first, and then Jenkins. It worked like a crisp.
We had the same issue after we upgraded to the latest version.
After some searching we decided to go with a lower version which has LTS support, 2.263.1 in this case.
That version worked instantly so I think this error is a bug.
we has similar issue, resolved by downgrading the jenkins.war file downloaded from URL: https://get.jenkins.io/war-stable/2.263.1/
I have faced similar issue, and found that we don't need to downgrade version.
Below are the steps I performed and it worked for me
upgrade global plugin i.e Role-based authorization strategy first from Jenkins Console.
Here are steps which I have performed:
#on ubuntu, in /usr/share/jenkins:
sudo service jenkins stop
sudo mv jenkins.war jenkins.war.old
sudo wget https://updates.jenkins-ci.org/latest/jenkins.war
sudo chown -R jenkins:jenkins jenkins.war
sudo service jenkins start
I have the same error on Jenkins 2.332.2 and updated plugin role-strategy v483.v17281966f5c3.
I had to download the version 3.2.0 of the plugin and put it directly in the jenkins plugins folder. (previously I remove the existing '.jpi' file)
Then restarting Jenkins /etc/init.d/jenkins restart, and the issue has gone.
Thank you for the intel!

Grails Geocode plugin dependency injection issue

Grails Version: 3.0.7
Groovy Version: 2.4.4
JVM Version: 1.8.0_51
I must be missing something really simple here.
I've added a grails plugin to my project as defined in the read me :
compile 'org.grails.plugins:geocode:0.3'
I can see the relevant dependencies have been pulled down from the repository.
However, when trying to inject the service within my controller using :
def geocodingService
I receive the following error upon execution :
Caused by: java.lang.NullPointerException: Cannot invoke method getPoint() on null object
The relevant line of code is :
Point location = geocodingService.getPoint('XXX XXX, UK')
My guess is the dependancy injection is failing but can anybody please tell me the mistake I am making?
Note : Copied my answer from another almost identical questions ...
OK, this seems to be down to me stupidly trying to use a grails 2.x plugin in a grails 3.x plugin.
There are various steps to go through to upgrade a plugin from 2.x to 3.x all detailed within the grails documentation.
My immediate solution was to simply create a new service and copy the code from the plugin into my application. Worked just fine.
Grails 3.x plugins : https://bintray.com/grails/plugins
Grails 2.x plugins : https://grails.org/plugins/
It's not obvious unless you navigate via the grails site. If you come in for example from Google directly to a plugin page, compatibility is shown as 2.5.x >
However, this actually seems to mean greater than 2.5.x but less than 3.x
Hope this helps should anyone else encounter this.

Grails error initializing application: null

When I try to run "grails run-app", I get the error and small stacktrace:
context.GrailsContextLoaderListener Error initializing the application: null
java.lang.NullPointerException
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:745)
I'm using Grails 2.5.0 and Java 1.8.0_51.
How can I get more information about what's going wrong?
edit: I've tried grails clean and grails refresh-dependencies in all related projects.
I think this is related to reloading or recompilation. Could you retry booting after a grails clean
Our app consists of two projects. Project 1 has all the Bootstrap files and Project 2 all the domain/view/controller files. The branch I was on for Project 1 had a bootstrap file which used a domain object that was on a different branch of Project 2, so I commented out the bootstrap file. As it turns out, this is what was causing the error. To fix it, I had to DELETE the bootstrap file to get the app to run.
I guess Grails doesn't like it when there's a Bootstrap file with no code in it..

"state is undetermined" when starting Grails app on CloudFoundry

I have a Grails app that has been running on CloudFoundry for months. I updated the app from Grails 2.0.4 to 2.1.0 and also updated a few plugins I have been using.
Now when I push the app to CloudFoundry and do the start, I receive the error:
'appname' state is undetermined, not enough information available.
The tomcat Catalina log shows the NoClassDefFoundError below.
I've read about issues with the Ivy cache but have not looked into that yet. I have updated vmc to the latest version (0.3.18).
SEVERE: Error deploying web application directory ROOT
java.lang.NoClassDefFoundError: org/apache/tomcat/PeriodicEventListener
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2818)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1159)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1647)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1128)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1026)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:840)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
at org.apache.catalina.core.StandardService.start(StandardService.java:525)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)
at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
Caused by: java.lang.ClassNotFoundException: org.apache.tomcat.PeriodicEventListener
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
... 34 more
I've just had this problem when migrating from Grails 1.3.7 to 2.1.1.
I fixed it by unpacking the WAR file, removing all the tomcat-*.jar files (there are several tomcat-embedded jars) and then restarting Tomcat.
I've got Tomcat 6 running and I wondered if that was the issue? Anyway my app is working for now--though it's not the best installation procedure!
I resolved the issue by rolling back to Grails 2.0.4 from 2.1.0. I think the issue might be the one described here. But the workaround provided by Graeme did not resolve the issue when deploying to cloudfoundry.com.
Running this app locally under Grails 2.1.0 had no problems but it would not work under cloudfoundry.com.
I'm not using CloudFoundry, but experienced the same issue deploying Grails 2.1 WARs to Tomcat 6. For now, I've configured _Events.groovy to remove the embedded tomcat- and grails-plugin-tomcat- jars from the WAR staging area right before WAR generation:
eventCreateWarStart = { warName, stagingDir ->
// Work-around to remove tomcat jars from .war.
File libDir = new File("${stagingDir}/WEB-INF/lib/")
if (libDir.exists() && libDir.isDirectory()) {
ant.echo(message: 'Events.eventCreateWarStart: Removing embedded tomcat .jars from .war.')
libDir.eachFileMatch(FileType.FILES, ~/^(tomcat|grails-plugin-tomcat).*\.jar$/) { File jarToRemove ->
jarToRemove.delete()
}
}
}
(The libDir.exists() && libDir.isDirectory() check may not be necessary.)
This is working for now, but it would be nice to get a real solution rather than a workaround.
I had the same issue with spring apps. After restarting the services ~cloudfoundry/vcap/dev_setup/bin/vcap stop, cloudfoundry/vcap/dev_setup/bin/vcap start I managed to push my application without any issue.Installin the CF on a more powerful machine may help. What is your current HW?
I know this question is about Grails and CF, but Google doesn't care too much about that... ;)
java.lang.ClassNotFoundException: org.apache.tomcat.PeriodicEventListener
may also appear when Eclipse WTP tries to publish a Maven-project and you run it. Somewhere in your hierarchy of dependencies you should find one to a tomcat-library, even if its scope is provided or test.
Check the lib-directory of your WTP-webapp and notice the bunch of tomcat-libraries in there.

IntelliJ IDEA/ Grails not resolving plugins

I have been using IntelliJ for almost a year ad I have always been really happy with it. However, yesterday I set it up on my new laptop (Ubuntu 11.04), and haven't seen the plugins module since.. :-(
Ran grails clean, tried to change the project structure/settings to include $HOME/.grails/1.3.x/projects/projectName/plugins, but still nothing. My understanding is that it should pick up the plugins automatically, am I right?
For the record, I am using Grails 1.3.4, IntelliJ IDEA Ultimate 9.0.4.
I'd strongly recommend switching to the latest Intellij version (10.5.1 as of now). Support for Grails has been improved a lot since 9.x. If you don't want to upgrade, check the following areas:
are all used classpath variables set correctly?
are you referencing the correct Grails version?
I'm using IntelliJ 11.1.3 with Grails 2.1.1.
General Issue:
The IDE Build/Make Project/Run Unit-tests sometimes fails to resolve classes referenced as dependencies within Plugins and produces 'no class...' errors. Normal grails targets (compile, run-app, test-app) work without issue!
Workaround:
Restarting IntelliJ 'magically' corrected my Plugin related 'no class...' errors.
What didn't work:
grails resolve-dependencies (makes sense because grails run-app worked fine!)
grails clean (again makes sense this is just purging the output)
Seems like the IDE Build/Make Project/Run Unit-tests uses a stale classpath in some circumstances. Unfortunately I don't have a repeatable test case but noticed that modifying BuildConfig and doing grails refresh-dependencies or compile or run-app doesn't make the IDE update it's list of grailsPlugins!
I've had IDEA do this once in a while to me as well. Even in the latest version (though I do agree you should upgrade, but 9->10 isn't free). For me, I just had to kill IDEA and restarted it.
IMPORTANT UPDATE! It will be fixed in 11.1.2! YEEAAAH!
In my case plugins not resolving because of custom system property 'grails.work.dir'. If your project using default 'grails.work.dir' than OK otherwise plugins won't be resolved. Tested on Idea 10.5.4, 11.1.1 and windows 7.

Resources