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")
}
}
Related
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.
I have the problem that migrateDb using Flyway in a Gradle project sometimes causes
Unable to obtain inputstream for resource: META-INF/db/mysql/V1__script.sql
This error doesn't occur all the time but only sometimes but if it happens it's quite persistent and also a clean/rebuild of the project doesn't solve it.
The SQL script that is mentioned is contained within a JAR file that is referenced from the project as part of a multi module project.
My researched only brought me to https://github.com/flyway/flyway/issues/702 but this didn't lead me to the right way.
I'm also very confused that flyway is able to find the file during the classpath search but is then not able to get the input stream.
If you should need any further info please ask.
Further debugging: It seems that the error seems to happen as soon as a new file is added to the DB JAR. After rebuild and migrateDb the error occurs. If I remove the script again the error still occurs although the script is not in the generated JAR anymore. So I guess the classpath for searching for scripts and retrieving input stream is different. Does anybody know what differences there might be?
Complete stack trace:
Caused by: org.flywaydb.core.api.FlywayException: Unable to obtain inputstream for resource: META-INF/db/mysql/V1__script.sql
at org.flywaydb.core.internal.util.scanner.classpath.ClassPathResource.loadAsString(ClassPathResource.java:84)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.scanForMigrations(SqlMigrationResolver.java:139)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(SqlMigrationResolver.java:99)
at org.flywaydb.core.internal.resolver.sql.SqlMigrationResolver.resolveMigrations(SqlMigrationResolver.java:49)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.collectMigrations(CompositeMigrationResolver.java:122)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.doFindAvailableMigrations(CompositeMigrationResolver.java:104)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(CompositeMigrationResolver.java:90)
at org.flywaydb.core.internal.resolver.CompositeMigrationResolver.resolveMigrations(CompositeMigrationResolver.java:43)
at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:114)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:164)
at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:157)
at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:75)
at org.flywaydb.core.internal.command.DbValidate.validate(DbValidate.java:157)
at org.flywaydb.core.Flyway.doValidate(Flyway.java:1280)
at org.flywaydb.core.Flyway.access$100(Flyway.java:71)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1176)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1168)
at org.flywaydb.core.Flyway.execute(Flyway.java:1650)
at org.flywaydb.core.Flyway.migrate(Flyway.java:1168)
at org.flywaydb.gradle.task.FlywayMigrateTask.run(FlywayMigrateTask.java:28)
at org.flywaydb.gradle.task.AbstractFlywayTask.runTask(AbstractFlywayTask.java:382)
Gradle Task:
// task that migrates the database
task migrateDb(type: org.flywaydb.gradle.task.FlywayMigrateTask) {
// parse hibernate config
def hibernateConfig = parseHibernateConfigByStageParameter()
// set config
url = hibernateConfig.url
driver = hibernateConfig.driver
user = hibernateConfig.username
password = hibernateConfig.password
locations = [ "classpath:${flywayDbPath}/${hibernateConfig.dbType}" ]
table = 'schema_version'
outOfOrder = true
ignoreMissingMigrations = true
}
Gradle dependency:
// dependencies
dependencies {
[...]
runtime project(':core:db:mysql')
[...]
}
During further testing I noticed that the error seems to be because of the Gradle Daemon. Adding --no-daemon to the migrateDb call works fine and doesn't trigger the error.
That's fine for me for now.
It turns out that I was deploying and old .war, which was built with some .sql files that were not around anymore.
Then I fixed this by running gradlew clean build
Can I not use the following Gradle approach to dependencies in Grails? I do not have nor want a parent directory;
https://stackoverflow.com/a/19303545/2288004
When I try it, I get the the following error;
Caused by: java.lang.IllegalStateException: Expected method not found:
java.lang.NoSuchMethodException:
org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedContext.addApplicationListener(org.apache.catalina.deploy.ApplicationListener)
It works when I use a parent directory for the settings.gradle, but unfortunately it’s not how I want to structure the project.
The following was indeed the solution I was looking for,
include ":myplugin"
project(':myplugin').projectDir = new File(settingsDir, '../myplugin')
The error was down to how I was managing my tomcat dependencies between the two projects.
Tomcat was already being pulled in via the plugin but while I still needed to reference tomcat at compile time in the application, I also needed to make sure it was the same version, and so added the following just above "dependencies" to target the version I required;
ext['tomcat.version'] = '7.0.70'
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 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?