"state is undetermined" when starting Grails app on CloudFoundry - grails

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.

Related

General error during conversion: java.lang.NoClassDefFoundError: org/codehaus/groovy/grails/commons/ApplicationAttributes

I am getting the following exception while running grails. Recently i have upgraded grails from version 2.x to 3.3.6. Please let me know what i am missing. Thanks General error during conversion: java.lang.NoClassDefFoundError: org/codehaus/groovy/grails/commons/ApplicationAttributes
java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/codehaus/groovy/grails/commons/ApplicationAttributes
at org.codehaus.groovy.control.CompilationUnit.convertUncaughtExceptionToCompilationError(CompilationUnit.java:1123)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1101)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:624)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:602)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:579)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:174)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:56)
at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerWorkerAdapter.execute(AbstractDaemonCompiler.java:73)
at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerWorkerAdapter.execute(AbstractDaemonCompiler.java:64)
at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:29)
at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerDaemonServer.execute(AbstractDaemonCompiler.java:91)
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)
This class was moved to grails.core.ApplicationContext, if it is in your code, so please update it to the new package. If it in the plugin seems that you need to update version or remove it(or you can upgrade it to grails 3 used docs)
This bug during the groovy compilation process i.e
General error during instruction selection: java.lang.NoClassDefFoundError:
could happen due to 3-4 things
A specific module that has the required dependency was not declared.
The dependency was declared but could have been declared with "implementation" in the build.gradle file rather than "api".
The dependency was declared but the compilation process may have gotten confused due to a mix of "compile" and "implementation" dependencies being simultaneously present on the compile classpath. It would be better to move all of them to the new gradle style and avoid 'compile' and 'testCompile' dependencies.
The compilation process has gotten confused due to some classes (of another module) being compiled with one version of a jar and some other classes being compiled with a more recent version. The best way would be to do a proper clean build of all modules.

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..

Vaadin upload works on localhost, but fails on server

The goal was to use the Vaadin upload-component to upload files. On localhost it just works fine while on the server I get the error message below.
I am running the application on a Glassfish 3.1.2 (build 23) and use Vaadin 7.4.1. Also have tried other Glassfish versions except Glassfish 4, as I have a dependency that is not yet ready for Glassfish 4.
Things tried or checked:
Size-limit: Not defined, files used ranged from 10kb to 500kb.
JVM version: Neither using the exact same version (1.7.0_52), nor playing with different patch-levels or java versions (1.8) changed the situation.
Possible port restrictions: Used more restricted and completely open security groups.
Provider: Tried Amazon AWS and DigitalOcean.
Fresh system: Set up a fresh system with just minimal installations to run the application.
Hardware resources: Whilst Amazon AWS (micro) is quite limited, the instance of DigitalOcean runs with 2 CPUs and 4GB ram.
Glassfish: Used several 3.x versions.
Upload component: Used the vaadin provided upload component and the addon easy uploads.
Things not checked:
OS: My dev system is running Windows 8.1 while the server is linux based.
Glassfish 4.x: As my jenkins deploy plugin is not yet ready for Glassfish 4.x I did not try that yet.
Vaadin: Did not yet downgrade Vaadin.
The code of the upload component looks like this, might have modified it some times trying to fix the error.
Upload-Component:
ImageUploader receiver = new ImageUploader();
upload = new Upload("", receiver);
upload.addSucceededListener(receiver);
addComponent(upload);
ImageUploader (as taken from Book of Vaadin):
class ImageUploader implements Upload.Receiver, Upload.SucceededListener {
public OutputStream receiveUpload(String filename, String mimeType) {
// Create upload stream
FileOutputStream fos = null; // Stream to write to
File file = new File(filename);
try {
fos = new FileOutputStream(file);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
... database stuff ...
// Return the output stream to write to, necessary for framework
return fos;
}
public void uploadSucceeded(Upload.SucceededEvent event) {
... UI-Stuff ...
}
}
Using this on a localhost instance works all fine. But having it deployed to a server makes it return the following error immediately upon hitting the upload-button. However there is no UI-error-message shown.
[#|2015-03-17T15:42:14.153+0000|WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=515;_ThreadName=Thread-2;|StandardWrapper$
java.io.IOException: The multipart stream ended unexpectedly
at com.vaadin.server.communication.FileUploadHandler.readLine(FileUploadHandler.java:302)
at com.vaadin.server.communication.FileUploadHandler.doHandleSimpleMultipartFileUpload(FileUploadHandler.java:360)
at com.vaadin.server.communication.FileUploadHandler.handleRequest(FileUploadHandler.java:285)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1408)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:350)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1542)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:745)
|#]
There is also a Vaadin [addon][3] that should make the process easier, but same results for localhost/server.
If it helps these technologies are used in the overall architecture:
Maven 3.2.1
Jenkins 1.602 (currently only used for build, not deploy)
Hibernate (not relevant, as the error occurs before hibernate is used)
MySQL (not relevant, as the error occurs before the database is accessed)
JDK: 1.7
IntelliJ Idea 14
Glassfish 3.1.2
Used server hosts are Amazon AWS and DigitalOcean.
Right now I don't have anymore clue what could fix this error. Any recommendations? Any further details I can provide?
-- UPDATE on JVM version --
Regarding the JVM I noticed that locally I recently installed 1.8 on my local machine. Using a 1.7 JVM does not reproduce the error.
-- UPDATE on JVM patch level --
Using the same patch level (1.7.0_75) in the development environment does not reproduce the error.
Upgrading to Glassfish 4.1 resolved the issue. The upload- and database-process now runs smoothly. However I was not able to identify the reason behind this issue.
Further information:
GlassFish Server Open Source Edition 4.1 (build 13)
I was pointed to a Vaadin-ticket that has the same issue, but the other way round: working with GF 4.1 but not with 3.1.
I was not able to search for another glassfish ticket that has something to do with this issue. If someone knows one, please tell me where I can add further information.

Liferay Portlet Error - "NoSuchResourceActionException <Portlet>_WAR_<PortletApp>#VIEW"

I have created a custom Liferay 6.2 portlet using Grails 2.0.4, the Portlets Plugin 0.9.2, and Liferay Portlets Plugin 0.4.
I am getting a strange error after deploying the portlet. Here is what happens:
Upload the WAR file through the web interface
Add the portlet to a page
Receive an error that says "There was an unexpected error. Please refresh the current page."
Refresh the page to find that none of the portlets on the page work anymore, and the following error is displayed: "Internal Server Error - An error occurred while accessing the requested resource." (see the image below)
The logs indicate the following error:
com.liferay.portal.NoSuchResourceActionException: <Portlet>_WAR_<PortletApp>#VIEW
I've seen other instances where the "#VIEW" says "#ADD_TO_PAGE". Please note that the portlet is deploying and working just fine on my vanilla version of Liferay 6.2 that I use for development.
Does anyone know what the issue could possibly be? Thank you.
Stacktrace:
Jan 16, 2014 10:42:40 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet jsp threw exception
com.liferay.portal.NoSuchResourceActionException: <Portlet>_WAR_<PortletApp>#VIEW
at com.liferay.portal.service.impl.ResourceActionLocalServiceImpl.getResourceAction(ResourceActionLocalServiceImpl.java:196)
at sun.reflect.GeneratedMethodAccessor308.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:115)
at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:175)
at com.sun.proxy.$Proxy85.getResourceAction(Unknown Source)
at com.liferay.portal.service.impl.ResourcePermissionLocalServiceImpl.doUpdateResourcePermission(ResourcePermissionLocalServiceImpl.java:1190)
at com.liferay.portal.service.impl.ResourcePermissionLocalServiceImpl.updateResourcePermission(ResourcePermissionLocalServiceImpl.java:1312)
at com.liferay.portal.service.impl.ResourcePermissionLocalServiceImpl.setOwnerResourcePermissions(ResourcePermissionLocalServiceImpl.java:1038)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:115)
at com.liferay.portal.spring.transaction.DefaultTransactionExecutor.execute(DefaultTransactionExecutor.java:62)
at com.liferay.portal.spring.transaction.TransactionInterceptor.invoke(TransactionInterceptor.java:51)
at com.liferay.portal.spring.aop.ServiceBeanMethodInvocation.proceed(ServiceBeanMethodInvocation.java:111)
at com.liferay.portal.spring.aop.ServiceBeanAopProxy.invoke(ServiceBeanAopProxy.java:175)
The problem ended up being higher in the stacktrace. I was receiving the following error:
net.sf.ehcache.CacheException: Unable to load class net.sf.ehcache.store.DefaultElementValueComparator
I was able to fix the problem by reading this link. Here are the steps I took:
Navigate to $liferay_home/tomcat/webapps/ROOT/WEB-INF/lib/
Copy ehcache.jar somewhere to back it up (like the root $liferay_home directory)
Copy ehcache.jar again somewhere to work with it (like the desktop)
Change the name ehcache.jar to ehcache.zip
Unzip the ehcache.zip file
Copy the updated ClassLoaderUtil.class file to the folder's net/sf/ehcache/util/ directory, replacing the current ClassLoaderUtil.class file.
Zip the ehcache directory
Change the name ehcache.zip to ehcache.jar
Put this new ehcache.jar file in $liferay_home/tomcat/webapps/ROOT/WEB-INF/lib/, replacing the current ehcache.jar
I don't know how portlets work wih grails but your error can be fixed by resolving how to define permission using grails.
Liferay official documentation about permissions can be found here :
http://www.liferay.com/community/wiki/-/wiki/Main/Permissioning+in+Plugin+Environment#section-Permissioning+in+Plugin+Environment-DEFINING+PERMISSION+FOR+A+PORTLET+RESOURCE+IN+PLUGIN+ENVIRONMENT
Since I use ehcache-2.10.4.jar in my project, I had the same issue after upgrading to Liferay EE 6.2.10 EE GA1. So instead of fiddling with compiled classes, I replaced ehcache.jar in the $liferay_home/tomcat/webapps/ROOT/WEB-INF/lib/ directory with the one that is provided by the Maven dependency.

SpringSource Tool Suite problem

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.

Resources