I have a Grails application running version 3.3. I recently upgraded to version 4.0.3. The way I typically upgrade, which I understand is probably not the best way, is to upgrade my environment to the new Grails version, then create a brand new Grails project (I'm using IntelliJ), and then slowly move my files over from the old project to the new project, fixing things as I find they don't work.
I have everything moved over and the app works perfectly while running run-app inside IntelliJ.
However, if I go to the terminal and run "grails war" I get all kinds of issues compiling assets. I don't typically pay much attention to how assets are handled (this is just a personal application).
I see that in my build.gradle file it's using asset pipeline plugin version 3.0.10 (com.bertramlabs.plugins:asset-pipeline-gradle:3.0.10). If I change these references back to the assetPipeline version that was being used in my Grails 3 app (2.14.2), then the errors go away. Does anyone know if there is a difference in these versions that could be causing my issue?
Here's a big chunk of the error stack:
...
Processing File 138 of 140 - redmond/images/ui-icons_cd0a0a_256x240.png
Processing File 139 of 140 - redmond/images/ui-icons_d8e7f3_256x240.png
Processing File 140 of 140 - redmond/images/ui-icons_f9bd01_256x240.png
> Task :Wolf:assetCompile FAILED
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.1/userguide/command_line_interface.html#sec:command_line_warnings
1 actionable task: 1 executed
<-------------> 0% WAITING
> Deleting unused version-specific caches in E:\java_dev\projects\Wolf4\.gradle
effects.unminified.js:720: ERROR - Object literal contains illegal duplicate key "scaleMode", disallowed in strict mode
scaleMode: {originalHeight: elementDimensions.height, originalWidth: elementDimensions.width},
^^^^^^^^^
Closure uglify JS Exception
asset.pipeline.processors.MinifyException: [Lcom.google.javascript.jscomp.JSError;#3ad6a23
at asset.pipeline.processors.ClosureCompilerProcessor.process(ClosureCompilerProcessor.groovy:80)
at asset.pipeline.processors.ClosureCompilerProcessor$process$0.call(Unknown Source)
at asset.pipeline.AssetCompiler$_compile_closure4.doCall(AssetCompiler.groovy:173)
at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:263)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
at groovy.lang.Closure.call(Closure.java:405)
at groovy.lang.Closure.call(Closure.java:399)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
rico.unminified.js:163: ERROR - Object literal contains illegal duplicate key "hoverTextColor", disallowed in strict mode
hoverTextColor : '#ffffff',
^^^^^^^^^^^^^^
Closure uglify JS Exception
asset.pipeline.processors.MinifyException: [Lcom.google.javascript.jscomp.JSError;#7bb4d5d3
at asset.pipeline.processors.ClosureCompilerProcessor.process(ClosureCompilerProcessor.groovy:80)
at asset.pipeline.processors.ClosureCompilerProcessor$process$0.call(Unknown Source)
at asset.pipeline.AssetCompiler$_compile_closure4.doCall(AssetCompiler.groovy:173)
at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:101)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:263)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
at groovy.lang.Closure.call(Closure.java:405)
at groovy.lang.Closure.call(Closure.java:399)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
unittest.unminified.js:457: ERROR - Object literal contains illegal duplicate key "benchmark", disallowed in strict mode
benchmark: function(operation, iterations) {
^^^^^^^^^
Closure uglify JS Exception
asset.pipeline.processors.MinifyException: [Lcom.google.javascript.jscomp.JSError;#3e732fc9
at asset.pipeline.processors.ClosureCompilerProcessor.process(ClosureCompilerProcessor.groovy:80)
at asset.pipeline.processors.ClosureCompilerProcessor$process$0.call(Unknown Source)
at asset.pipeline.AssetCompiler$_compile_closure4.doCall(AssetCompiler.groovy:173)
at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
I have reverted back to the previous version of the assetPipeline plugin and that allows me to compile without error.
But for anyone else that comes across this, I noticed that after upgrading Grails I was having issues with the war version of my application once it was deployed to Tomcat.
First issue -
war {
archiveName "Wolf.war"
}
No longer named my war file as desired. I asked about this in a different question
and the first answer was to use bootWar instead of war, such as:
bootWar {
archiveName "Wolf.war"
}
This did indeed name the war file correctly. However, now when the war file was dropped into tomcat, and tomcat exploded it, it included an org.springframework.boot.loader folder inside the webapp which I didn't previously have. This doesn't seem right.
In addition, I no longer had the assets directory, so all of my custom js, css, and images were missing from the deployed app.
After much googling, I found something that suggested doing this:
war {
enabled = true
archiveName "Wolf.war"
}
This resolved all my issues. My war file is named correctly, the war file contains the assets, and the war file does not contain the boot folder. And, the deployed app works correctly.
So, I don't know if this is the "proper" way that I should be doing it, but it works.
The error is being very clear here. Uglification process is detecting a duplicate key definition in a Map object in your js and its telling you to fix it. This is an improvement overall to help you find code errors. Some browsers will ignore this and some older ones won't so its just trying to help you out.
Related
I'm currently trying to migrate one of my older JavaFX projects to compose-jb desktop.
To make the new application compatible with the old one, i want to continue distributing fat jars.
Right now, i'm able to build the fat jar but whenever i try to run it via jar -jar ... it just fails with the following error:
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
at java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:317)
at java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:259)
at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:273)
at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:230)
at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:759)
at java.base/java.util.jar.JarFile.ensureInitialization(JarFile.java:1038)
at java.base/java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:69)
at java.base/jdk.internal.loader.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:870)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:786)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:760)
at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:655)
I've read that this is because some jars i depend on are signed, so i tried to add the following lines to exclude signature files:
tasks {
withType<Jar> {
exclude("META-INF/*.RSA", "META-INF/*.SF", "META-INF/*.DSA")
}
}
However, it seems like compose-jb still includes those files in the fat jar:
I would really appreciate any advice on how to fix this.
Source: https://github.com/DarkAtra/bfme2-patcher/blob/ceb801bdd0304d5b863909616b53aaf7d96c5064/build.gradle.kts#L58-L62
GH Post: https://github.com/JetBrains/compose-jb/discussions/2290
Seems like i was using the wrong Jar type in withType<Jar>.
After changing it to org.gradle.jvm.tasks.Jar it correctly excluded all signature related files from the uber jar.
tasks {
withType<org.gradle.jvm.tasks.Jar> {
exclude("META-INF/*.RSA", "META-INF/*.SF", "META-INF/*.DSA")
}
}
I'm trying to generate a runnable jar file of my project which has a JavaFx gui.
The project runs greate in eclipse but whenI try to run the jar:
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
...Caused by: java.lang.NullPointerException: Input stream must not be null
The code for the images looks like:
private Image image1 = new Image(this.getClass().getResourceAsStream("../pic/classic/image1.png"));
What do I need to change so that i can run my jar file with no exception.
Thanks for the help.
The .. is not valid in specifying a resource name in a jar file. According to the documentation on resource naming each component of the resource path should be a valid Java identifier: .. is not.
To fix this, just specify the absolute resource name, relative to the classpath. So if the class you are in is in a package called com.mycompany.myapplication.view, you would use
private Image image1 =
new Image(this.getClass().getResourceAsStream("/com/mycompany/myapplication/pic/classic/image1.png"));
Keep in mind, that image file names are CASE SENSITIVE within jar and are not in IDE (e.g. Eclipse).
So if you have "/resource/image.jpg" argument and IMAGE.jpg filename, application will work in Eclipse and, being exported to jar, will produce NullPointerException in
Image image1 = new Image(getClass().getResourceAsStream("/resource/image.jpg"));
I would like to ask your help in the following case.
I'm currently using Cloudera CDH 5.1.2 and I tried to collect Twitter data using Flume as it is described in the following porsts (Cloudera):
http://blog.cloudera.com/blog/2012/10/analyzing-twitter-data-with-hadoop-part-2-gathering-data-with-flume/
github.com/cloudera/cdh-twitter-example
I downloaded the source and rebuilt the flume-sources after updating the versions in pom.xml:
<flume.version>1.5.0-cdh5.1.2</flume.version>
<hadoop.version>2.3.0-cdh5.1.2</hadoop.version>
It worked perfectly.
After that I wanted to add a "language" filter, to capture only the tweets of a specific language. For this, I modified the TwitterSource.java to call the FilterQuery.language method somehow like this:
FilterQuery query = new FilterQuery();
...
if (languages.length != 0) {
query.language(languages);
}
I'm trying to use twitter4j-stream version 3.0.6. I updated it in pom.xml:
<!-- For the Twitter API -->
<dependency>
<groupId>org.twitter4j</groupId>
<artifactId>twitter4j-stream</artifactId>
<version>3.0.6</version>
</dependency>
With these settings I rebuilt the jar (mvn package).
When I start my agent, I get the following exception (NoSuchMethodError):
Unable to start EventDrivenSourceRunner: { source:com.cloudera.flume.source.TwitterSource{name:Twitter,state:IDLE} } - Exception follows.
java.lang.NoSuchMethodError: twitter4j.FilterQuery.language([Ljava/lang/String;)Ltwitter4j/FilterQuery;
at com.cloudera.flume.source.TwitterSource.start(TwitterSource.java:165)
at org.apache.flume.source.EventDrivenSourceRunner.start(EventDrivenSourceRunner.java:44)
at org.apache.flume.lifecycle.LifecycleSupervisor$MonitorRunnable.run(LifecycleSupervisor.java:251)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
I checked, and this version of twitter4j-stream contains the language method:
github.com/yusuke/twitter4j/blob/3.0.6/twitter4j-stream/src/main/java/twitter4j/FilterQuery.java
What am I doing wrong?
Thanks in advance,
Peter
Finally I managed to solve this problem. So here's the solution to anyone out there facing the same issue.
First (in the above case in the original post) I placed my generated jar to /var/lib/flume-ng/plugins.d/twitter-streaming/lib/, and set it up in the Cloudera Manager config to use this location.
In this case the CM placed this directory to the and of the classpath in the runner file (after the parcel directory). So the directory order in the classpath looked like this:
/opt/cloudera/parcels/CDH-5.1.2-1.cdh5.1.2.p0.3/lib/flume-ng/lib/*
/var/lib/flume-ng/plugins.d/twitter-streaming/lib/*
Unfortunately there was a twitter4j-stream-3.0.3.jar and twitter4j-core-3.0.3.jar in the parcel directory, and flume tried to use that instead of 3.0.6, and in that version FilterQuery.language obviously doesn't exist.
So I just deleted those jars from the parcel directory, and it works fine now.
I tried this with cdh3 and it worked fine with me. One of the thing i noticed was system time should be set to current time. In your case, I think it is looking Language method in FilterQuery class.
I'm running Jenkins 1.478 on CentOS, using Java 6, Maven 3.0.4, JUnit 4.8.1 (dependency within the Maven project), and Sonar 3.2.1. I have my Jenkins Maven 2/3 job setup to run Sonar after it completes (set with goals "clean package -Pdev"). The project is a multi-module project with WAR and EAR modules. However, when the Sonar portion of the plugin runs, many of the tests die with errors like below …
java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:418)
at java.util.Properties.load0(Properties.java:337)
at java.util.Properties.load(Properties.java:325)
at org.parentco.myco.client.test.AbstractHibernateDaoTest.loadmyprojectProps(AbstractHibernateDaoTest.java:252)
at org.parentco.myco.client.test.AbstractHibernateDaoTest.setupMockEjbContainer(AbstractHibernateDaoTest.java:235)
at org.parentco.myco.client.test.AbstractHibernateDaoTest.setupBeforeClass(AbstractHibernateDaoTest.java:72)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
The exception comes from the last line of this code block ...
final InputStream in = AbstractHibernateDaoTest.class.getClassLoader().getResourceAsStream("myproject.properties");
final Properties props = new Properties();
props.load(in);
The test runs perfectly during the Maven portion of my job. The file in question is located at
./myclient-war/src/main/resources/myproject.properties
Anyone know how I can troubleshoot this further? I would prefer to configure something in Sonar as opposed to having to restructure my entire project to accommodate Sonar, but I'm open to suggestions.
It could be due to Sonar creating a separate class loader for running each test, although I am not quite sure.
I believe all the tests failing follow hierarchy?
YourTestClass extends AbstractHibernateDaoTest
Try loading the file using the classloader of the immediate test class that is YourTestClass instead of always trying to load it using class loader of AbstractHibernateDaoTest
Try changing your code to,
final InputStream in = this.getClass().getClassLoader()
.getResourceAsStream("myproject.properties");
final Properties props = new Properties();
props.load(in);
This will ensure that you are getting class object of your actual test class instead of the abstract one and also the class loader of the immediate class instead of one already loaded.
UPDATE:
I
I feel what is happening is that whatever class loader is being used in your code to load the resource, is not able to see the Maven's class loader. Note that Maven and particularly maven-surefire-plugin in your case is responsible for setting the right classpath. It will be adding the src/main/resources directory on the classpath.
Try "/myproject.properties".
ClassLoader cl = AbstractHibernateDaoTest.class.getClassLoader();
InputStream inTmp = cl.getResourceAsStream("myproject.properties");
if(itTmp==null){
itTmp=cl.getResourceAsStream("/myproject.properties");
}
final InputStream in = inTmp;
One possibility is this issue:
Spring-based junit tests clash with Cobertura plugin Sonar uses. Workaround is to use JaCoCo or EMMA plugin instead of Cobertura.
I would like to use JDOM in a Webapp project. This works just fine. But now I want to add some stuff using XPath, but if I try to work with an XPath, I just get an exception:
com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: Uncaught exception created in one of the service methods of the servlet MyServlet in application MyProjectEAR. Exception created : java.lang.NoClassDefFoundError: org.jaxen.BaseXPath
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:136)
at org.jdom.xpath.XPath.newInstance(XPath.java:126)
at org.jdom.xpath.XPath.selectNodes(XPath.java:337)
[..]
Caused by: java.lang.ClassNotFoundException: org.jaxen.BaseXPath
at java.net.URLClassLoader.findClass(URLClassLoader.java:421)
at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:150)
at java.lang.ClassLoader.loadClass(ClassLoader.java:652)
at com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:90)
at java.lang.ClassLoader.loadClass(ClassLoader.java:618)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:62)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:58)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:540)
at java.lang.ClassLoader.loadClass(ClassLoader.java:618)
... 35 more
The jaxen.jar is in my classpath, and the org.jaxen.BaseXPath class is there just fine. Why is Websphere not finding it? It works with all the other libraries I have there. When googling I found this, where someone says that he has a conflicting version somewhere and I should make sure that jars from my web app directory have precedence. In eclise' Built Path Configuration I set Web App Libraries above the WebSphere library (only the src dir is now above the web app libs), but that did not change anything. Unfortunatelly I did not really understand the part about the EAR which seems important...?
Update: In the meantime this gave me a new clue. I found on WebSphere's Administration Console the classpath and a list with all jars that are considered by the class loaders. These are quite a number and I searched them with a little grep and unzip -l magic and figured that the file /opt/ibm/WebSphere/PortalServer/wcm/prereq.wcm/wcm/shared/app/jdom.jar contains jdom (without the jaxen stuff). So maybe this jdom jar is loaded, but jaxen in an incompatible version is loaded from my lib directory?
Additionally I found in WebSphere's Administration Console the "parent first/last" setting for my application, but everything is grayed out! I can't switch to parent last :-(.
What can I do to find and fix the problem?