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"));
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 am building a spring boot application. I want to configure my database properties externally, so anyone can run war file from any machine. How do I configure application.properties externally? I am following this documentation http://docs.spring.io/autorepo/docs/spring-boot/1.0.1.RELEASE/reference/html/boot-features-external-config.html
So I created a app.properties file in jetty's home directory.
spring.datasource.url=jdbc:sqlserver://mymachine:1433;databasename=TESTDB
spring.datasource.driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver
spring.datasource.username=someuser
spring.datasource.password=somepass
And trying to run war file through jetty, but it is not detecting application.properties for some reason.
java -jar ../start.jar --spring.config.location=file:///E:/Tools/jetty-distribution-9.3.12.v20160915/demo-base/webapps/app.properties
When I run above command, I get following error in jetty
Caused by:
java.lang.IllegalArgumentException: Property 'driverClassName' must not be empty
at org.springframework.util.Assert.hasText(Assert.java:168)
at org.springframework.jdbc.datasource.DriverManagerDataSource.setDriverClassName(DriverManagerDataSource.java:1
24)
at com.abc.mycompany.sts.config.settings.PersistenceContext.dataSource(PersistenceContext.java:55)
at com.abc.mycompany.sts.config.settings.PersistenceContext$$EnhancerBySpringCGLIB$$368bb66a.CGLIB$dataSource$2
(<generated>)
at com.abc.mycompany.sts.config.settings.PersistenceContext$$EnhancerBySpringCGLIB$$368bb66a$$FastClassBySpring
CGLIB$$25ca0903.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(Configurati
onClassEnhancer.java:356)
at com.abc.mycompany.sts.config.settings.PersistenceContext$$EnhancerBySpringCGLIB$$368bb66a.dataSource(<genera
ted>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy
.java:162)
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolv
er.java:588)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(Ab
stractAutowireCapableBeanFactory.java:1128)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutow
ireCapableBeanFactory.java:1022)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCap
ableBeanFactory.java:512)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapab
leBeanFactory.java:482)
This is my jetty's directory structure
E:\Tools\jetty-distribution-9.3.12.v20160915\demo-base\webapps
On command line I am starting jetty by going to demo-base and running command
java -jar ../start.jar --spring.config.location=file:///E:/Tools/jetty-distribution-9.3.12.v20160915/demo-base/webapps/app.properties
The bean looks like below where I am trying to access properties from external application.properties file
#Bean
public DataSource dataSource() {
final DriverManagerDataSource dataSource = new DriverManagerDataSource();
dataSource.setDriverClassName(env.getProperty(ConfigConstants.DATABASE_DRIVER_CLASS_NAME));
dataSource.setUrl(env.getProperty(ConfigConstants.DATABASE_URL));
dataSource.setUsername(env.getProperty(ConfigConstants.DATABASE_USERNAME));
dataSource.setPassword(env.getProperty(ConfigConstants.DATABASE_PASSWORD));
return dataSource;
}
This doesn't find my app.properties file. What am I missing?
I see you use env properties to initialize datasource and I would suggest another one solution for you.
Proposition one: it is possible to set properties value on startup like:
java -jar ../start.jar --spring.datasource.url=jdbc:sqlserver://mymachine:1433;databasename=TESTDB --spring.datasource.driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver --spring.datasource.username=someuser --spring.datasource.password=somepass
Or if you want mask property names, define your own properties. You have to pack following application.properties file into you jar:
spring.datasource.url=${APP_DB_URL}
spring.datasource.driver-class-name=${APP_DB_DRIVER_CLASS}
spring.datasource.username=${APP_DB_USERNAME}
spring.datasource.password=${APP_DB_PASSWORD}
Next. Before run application set env properties. On *nix platform:
export APP_DB_URL=jdbc:sqlserver://mymachine:1433;databasename=TESTDB
export APP_DB_DRIVER_CLASS=com.microsoft.sqlserver.jdbc.SQLServerDriver
export APP_DB_USERNAME=someuser
export APP_DB_PASSWORD=somepass
On windows platform:
set APP_DB_URL=jdbc:sqlserver://mymachine:1433;databasename=TESTDB
set APP_DB_DRIVER_CLASS=com.microsoft.sqlserver.jdbc.SQLServerDriver
set APP_DB_USERNAME=someuser
set APP_DB_PASSWORD=somepass
And finally, just run your jar without any params:
java ../start.jar
I hope this post could be helpful for you.
Put your application.properties file under JETTY_HOME/resources folder and add
--module=resources
line to start.ini file.
Second one add resources folder to classpath, so every file under that directory will be in the classpath of your webapp.
This should work.
--spring-config-location
is not the correct property name. The property uses dot-notation, not hyphens.
Try:
--spring.config.location
For more information, see section 24.3 in the documentation: http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
Additionally, you should point to the directory where the application.properties will be located instead of to the specific file. That may help, but is more useful when you later want to specify profiles. Spring Boot can then select the correct properties file base on profile. For example:
--spring.config.location=file:///E:/jetty/demo-base/webapps/
If you had multiple files in this directory like:
application.properties
application-dev.properties
application-prod.properties
You could add the
--spring.profiles.active=prod
To select the prod properties.
You have too many slashes in the path to the file after "file:" protocol and backslashes should be used too:
--spring.config.location=file:E:\Tools\jetty-distribution-9.3.12.v20160915\demo-base\webapps\app.properties
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 have a java/maven project that uses tango icons, so I'm using the following dependency:
<dependency>
<groupId>org.freedesktop.tango</groupId>
<artifactId>tango-icon-theme</artifactId>
<version>0.8.90</version>
</dependency>
And the following code, which would work ok before I moved the proyect to maven:
imageIcon = new ImageIcon(this.getClass().getResource(org/freedesktop/tango/22x22/actions/address-book-new.png));
However, it now results in NullPointerException for some reason.
The generated jar does not contain the images, nor reference them in any way, but classes in other jars are.
I've investigated a lot, but I've found most people bundle their images with their source. This isn't my case.
What do I need to do for maven to reference and/or package these images propertly?
How can I get maven to build a standalone runnable jar (this is a swing application).
If you add a slash before the path it works:
ImageIcon imageIcon = new ImageIcon(this.getClass().getResource("/org/freedesktop/tango/22x22/actions/address-book-new.png"));
From the API:
Before delegation, an absolute resource name is constructed from the
given resource name using this algorithm:
If the name begins with a '/' ('\u002f'), then the absolute name of
the resource is the portion of the name following the '/'. Otherwise,
the absolute name is of the following form:
modified_package_name/name Where the modified_package_name is the
package name of this object with '/' substituted for '.' ('\u002e').
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?