I have a grails application that i have deployed on my linode box. It was running fine for a few days but now gives this error on all pages:
Caused by: java.lang.VerifyError: (class: org/codehaus/groovy/runtime/InvokerInvocationException, method: getMessage signature: ()Ljava/lang/String;) Illegal constant pool index
Googling indicates that this is a weaving problem, but not how to solve. Has anyone encountered something similar?
I've just worked around this error in gwt... I don't have time to try all the possible values for the variables involved but it appears it was related to using different version of javac for different parts of the process... I was compiling the gwt code using jdk5 and running app code in jre6
Related
I've got a problem with incorrectly deployed Google App Engine instances - I deployed 3 instances with invalid entry point script which failed (error is raised and sent to Sentry).
The application is Ruby on Rails project and the failing part is rails db:migrate part.
Even when I disabled the whole application the GAE is Creating VM, then the error is raised and then is Deleting the VM. Those instances were removed from webpage console and all 3 of them are from one service.
The GAE tries to deploy them which causes usage of resources (also the IP quota etc are used so I cannot do anything tbh) and the failures are available in logs - where I can see the whole stacktrace with the prefix in form of: api[20190429t085718] ([]).
I can find a resource by searching by this timestamp - they are appearing in search results, but when I click on them the message that they are "Not found"/"Not existing" appears.
How can I delete them? Or will they be deleted?
If anyone encounters such a problem and founds this post: problem was solved after ~6h, instances stopped deploying (so it was enough to just wait)
I am trying to use 2.0.0-M1 version of grails plugin for neo4j but when i try to save any entity,it is giving me error :
The instance was updated by another user while you were editing. Stacktrace follows: org.grails.datastore.mapping.core.OptimisticLockingException: The instance was updated by another user while you were editing at org.grails.datastore.gorm.neo4j.NodePendingUpdate.run(NodePendingUpdate.java:83)
and if i try to use 2.0.0-M2 version,i got error :
groovy.lang.MissingMethodException: No signature of method: groovy.util.ConfigObject.startsWith() is applicable for argument types: (java.lang.String) values: [jdbc:neo4j:instance:]
Also tell me if 2.0.0-M2 is supporting rest or not.
Please reply fast.
Configuration has changed significantly from M1 to M2. Internally the plugin now uses the Neo4j JDBC driver. I didn't yet found enough time to update the docs, in the meantime refer to https://github.com/sarmbruster/neo4jsample/blob/neo4j_2.0/grails-app/conf/DataSource.groovy for a valid sample config.
The error you're mentioning seems to be caused by a incorrect configuration.
M2 is capable of working with remote database, just set datasource.url="jdbc:neo4j://localhost:7474/", see https://github.com/sarmbruster/neo4jsample/blob/neo4j_2.0/grails-app/conf/DataSource.groovy#L13
We are trying to run JSFUnit with Arquillian on a WebLogic 12c container and are running into a few problems.
First, when we try to use the #InitialPage annotation to inject in the JSFServerSession and JSFClientSession, the JSFServerSession is always returned as null.
Second, we have tried working around the problem by going the legacy route of creating a new JSFSession and then getting the JSFServerSession and JSFClientSession from it. Once we run a second test we get "java.lang.IllegalStateException: Can not find HttpSession. Make sure JSFUnitFilter has run and your test extends org.apache.cactus.ServletTestCase."
It seems very arbitrary because there are times where we will run a test and it passes. Sometimes the very next time it fails. Or adding a line that doesn't seem like it should be related, will thrown the "Can not find HttpSession" error.
It seems like it can't handle creating the JSFSession multiple times or there is some timeout on the server that even though the test war is getting undeployed something needs to timeout. Any thoughts?
I am not sure if this applies to your problem as well, but I had similar issue with JBoss 7. Usually the issues can be solved by:
Using Servlet 3.0 protocol which should include relevant filters to web.xml
If that doesn't help (like in my case), use this solution: https://stackoverflow.com/a/17036005/1667977
In any case, try to avoid creating the session yourself
I have a fresh and clean Tomcat7 ready in my Windows machine, when I remove the JSF jars (jsf-api-2.0.1.jar and jsp-impl-2.0.1.jar) from WEB-INF/lib, I hit this error:
Caused by: java.lang.ClassNotFoundException: javax.faces.FacesException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
... 10 more
When I put the 2 jars in WEB-INF/lib, I hit error:
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
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:1148)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1643)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:1956)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:1919)
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1806)
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1765)
at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1751)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1255)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:882)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:317)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5081)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:774)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:291)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:727)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.startup.Catalina.start(Catalina.java:620)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Any clue on running JSF in Tomcat 7?
You haven't indicated if the error occurs instantly on deploy or after a while. If it occurs after a while, i.e. during your application run, your code will be to blame. Look at this excellent article that will help you use JDK 6 track down the source of the error.
A PermGen error is indicative of classloading issues pertaining to your application container.The Permanent Generation (PermGen for short) is the area where the JVM stores objects such as classes and string literals. Normally, the garbage collector is not supposed to operate frequently here. Classes loaded by the app server should be automatically cleaned up once the classloader for the web application (there is one per deployed webapp) is no longer being used. Tomcat has given me problems in this area in the past (especially when used within Netbeans). It seems to not be able to clean up after itself effectively after repeated redeploys. There are a handful of things you could do apart from increasing the size of the permgen space
1) You could move the common jars for the web applications running in that tomcat instance into the TOMCAT_HOME/lib. This way, you can expect your class libraries to not be loaded multiple times per requiring web application as is the default behaviour for tomcat(see this). Use this option with care however; if you eventually deploy a web application containing newer versions of the jar, you might run into NoClassDefFound errors.
2)You can try this -XX:MaxPermGen instead of (or in addition to) the -XX:MaxPermSize that mkyong suggested in his article.
Also take a look at this question and it's answers for further steps
Has anyone around gotten Openfaces 3.0 to run on WebSphere 7.0?
I keep on getting the following error:
java.lang.NullPointerException
at javax.faces.application.ResourceWrapper.getRequestPath(ResourceWrapper.java:118)
at org.openfaces.application.OpenFacesResource.getRequestPath(OpenFacesResource.java:36)
at org.openfaces.util.Resources.getInternalURL(Resources.java:133)
at org.openfaces.util.Resources.getUtilJsURL(Resources.java:234)
at org.openfaces.util.UtilPhaseListener.appendHeaderContent(UtilPhaseListener.java:60)
at org.openfaces.application.OpenFacesApplication.headAddedToView(OpenFacesApplication.java:79)
Any ideas? Thanks in advance.
floshton.
I don't do OpenFaces/Websphere, so I can't go in detail about this, but given the fact that ResourceWrapper#getRequestPath() delegates as per its source code the call as follows
return getWrapped().getRequestPath();
Where ResourceWrapper#getWrapped() is an abstract method which is to be implemented properly by the implementor. Given the trace, it's the org.openfaces.application.OpenFacesResource which is incorrectly returning null on getWrapped().
What the underlying cause is, is unclear since I don't have the hands on OpenFaces source code directly. I'd start by reporting this issue to the OpenFaces guys on their forum and/or issue tracker.