I have built a jar file which has a log4j.properties file in it (mvn package put it there by default from the resources directory). But when I run this jar file, I want to pass a different logging config, so I add -Dlog4j.configuration=file:{path to file}. The issue that bugs me is that the order matters here as follows:
When I run java -jar {path to jar} -Dlog4j.configuration=file:{path to file} then it reads the log file packaged in the jar.
When I run java -Dlog4j.configuration=file:{path to file} -jar {path to jar}, then it reads the config from the file I pass in the parameters.
I have rough understanding how classpaths work in java and that if I were to load several java classes with the same name, it would make a difference. But this way I am passing a config parameter with a -D prefix, so the way I expect this to work is for some code in log4j library to check whether -Dlog4j.configuration is set and if so, then load the config from there, otherwise try to find it on the classpath.
Any ideas on what I am missing?
If you provide anything after naming the JAR file, it is treated as an argument to your main method. For Log4J you actually have to define a property, and this needs to be done before you specify -jar.
Related
I have an internal application.yml configuration file located in the resources folder on classpath.
I have an external configuration file: /home/username/config.properties which overrides some fields to run in a server context.
I want the fields in the external config file to override internal file and retain the fields in the internal file if not defined in external file.
The answers suggested Spring - how to override internal config file with external file doesn't work.
For example, the following command doesn't works for me:
java -jar application.jar --spring.config.location=classpath:/,file:///home/minister/config.properties
How do I achieve this desired outcome?
EDIT: This issue only happens on Linux. When I run it with the overriden configuration file on my Windows 10 machine, it works properly.
Looks like you have one too many /, try:
java -jar application.jar --spring.config.location=classpath:/,file:/home/minister/config.properties
You can pass the path to file, relative to the .jar file, for example,
java -jar application.jar -Dspring.config.location=./config/application.properties
or
java -jar application.jar -Dspring.config.location=../common/config
either of these work. Please refer - Spring Documentation for further details on how externalized configuration works.
Hope this helps.
I have written a small application to parse a large XML file using SAX with Intellij.
I pass -DentityExpansionLimit=0 option to my application by going to Run\Edit Configurations... and set VM options.
It works perfectly when I run the application with Intellij, but when I create the artifact with intellij it doesn't work and I get the error which needed to set that option. This is obvious that the option didn't pass to the created jar file.
How should I achieve this goal?
Is there any command that I create with a batch file or something to set this option for my user? Is there any setting file that I can modify to set this option for my machine? (I use windows 10)
Usually, to send system properties to a jar, the command is something like that:
java -DentityExpansionLimit=0 -jar thejar.jar
You are mixing up two things here:
the JVM command line command, and the fact that you can pass arguments to your application, or properties to the JVM itself
your deployment artefact (probably a JAR file)
Meaning: It seems like you want to either pass command line arguments (to some main function) or properties to your application. But the JAR file doesn't have support for that.
JAR files are just a container of class files. You can add some META information via the manifest (which class to run), but that is about it. You can't magically push your IntelliJ "runtime configuration settings" into the JAR.
In other words: IntelliJ has no way of putting these values into your JAR.
When you invoke java -jar Your.jar ... then you (or some other tooling) has to add the required values to the command line.
I'm trying to get my application classpath.
I have a jar (named application.jar) and it have in its Manifest.mf other jar files, like Class-Path: a.jar b.jar.
Why when I use System.getProperty("java.class.path") my jars a.jar and b.jar are not listed?
It possibly has to do with the fact that the java.class.path is a system property that is set from the classpath environment variable ($CLASSPATH or -classpath). These are ignored with the -jar option is used.
As per the java -jar documentation, when that jar option is used to run an application, only the manifest Class-Path is considered and other settings are ignored.
From http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html:
-jar
Execute a program encapsulated in a JAR file. The first argument is the name of a JAR file instead of a startup class name. In order for this option to work, the manifest of the JAR file must contain a line of the form Main-Class: classname. Here, classname identifies the class having the public static void main(String[] args) method that serves as your application's starting point. See the Jar tool reference page and the Jar trail of the Java Tutorial for information about working with Jar files and Jar-file manifests.
When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored.
That's excactly the question I came along as well. Even if when using java -cp ..;myTest.jar test2.Needer I get only "..;myTest.jar" as a result for java.class.path property.
Note: Even when using the -cp parameter the given class-path in the MANIFEST.MF is searched! (Couldn't find this information on google and tested myself)
So i don't think that is has something to do with the -jar parameter. In Link you can find
Expansion of wildcards is done early, prior to the invocation of a program's main method, rather than late, during the class-loading process itself.
Interestingly i found out during my tests: The classpath in MANFIFEST.MF is searched recursivly. So if there is an given test.jar File in the classpath in MANIFEST.MF of myTest.jar, the class-path in the MANIFEST.MF of the test.jar will be looked up as well (when using java -cp "myTest.jar" test2.Needer).
As a result, when the java.class.path property would support showing the the classpath of the MANIFEST.MF, it should also show the classpathes of all subsequently depending .jar files. Since the classpath is only searched until classes are found, this wouldn t refer nicely to the lazy loading mechanism.
TL;DR: I think that this has nothing to do with the -jar Parameter (-cp is concerned as well). In my explanation, the support for showing the classpath from the MANIFEST.MF would only come with additional, senseless recursive search costs (because there needn't to be an actual dependency, respectivly what is used from the .jar). And since this sensless search would delay the program start (since the recursive search could be really deep), it is not implemented.
I have an application contained in A.JAR. This jar has several dependencies so they are specified in the manifest as "lib/B.JAR lib/C.JAR lib/D.JAR". I have my installation directory with A.JAR, and under it I have the lib directory with the three others.
I go to my installation directory and run "java -jar A.JAR" to run the application, and it starts running. However, it looks for log4j.properties for setting up log4j. Now as far as I know, log4j.properties needs to be in the classpath.
Now let's suppose I want to run several instances of A.JAR, but with various log4j properties. So I setup 4 installation directories (inst1, inst2,...) and I've put A.JAR, a customized log4j.properties and the lib directory in each of them.
Is this the right way to go (forget about the copying itself, I can do this with symlinks)? Maybe there's a way for telling log4j to look for the properties in a specific place using some define (-D) in runtime?
If what I've described is a good setup, how can I actually run it? Java doesn't "catch" the log4j.properties as part of its classpath. running "java -classpath . -jar A.JAR" wasn't helpful as well.
You can use the log4j.configuration system property to define the properties files you want log4j to use.
A simple example for a file in some directory would be:
java -Dlog4j.configuration=file:/c:/foobar.properties YOUR CLASS PATH -jar JAR FILE
For more information check the documentation. Especially check the Default Initialization Procedure section.
When I finished to write my classes I put them into a package structure and then I jarred all.
Now which is the best way to deploy and use my jar?
setting classpath;
use CLASSPATH variable;
using the extension mechanism.
Don't update the user's CLASSPATH environment variable because there is a risk that your deployed application will interfere with other Java applications that the user might want to run.
Don't deploy using the Extension mechanism because there is a risk that you will interfere with applications run by any user using the JVM that you have "extended".
The best solution is to create and deploy a wrapper script that uses the "-cp" argument, or a shortcut that runs a self-launching JAR file ... as suggested by other answers.
I you have a main class in that jar that you want to run the best approach is to put a META-INF/MANIFEST.MF file in the jar and launch your class using java -jar mypackage.jar
The manifest should contain a Class-Path and a Main-Class attribute
See http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR%20Manifest
If you mean by 'deploy and use' that you want to use it in another application, set it on the classpath of that application.
If you use the extension mechanism (I assume you mean putting the jar in pathtojava/lib/ext) every application using that jvm will have the jar loaded, the samecounts for the CLASSPATH as system variable. That is most likely not necessary?
If you ment to execute/use the jar as standalone application; just run it commandline, no classpath stuff needed. If you want to deploy on a server you probably wanted to make a war or ear fiel instead.
Best to my opinon is to provide batch files and shell scripts to start the application.
Sophisticated scripts check for environment variables like $JAVA_HOME (%JAVA_HOME%) and use them, if defined or use a default value.
Inside the script you could build the classpath in an internal variable and start the app with a line like
%JAVA_HOME%\bin\java.exe -cp %LIBRARIES% com.example.Main
I would prefer this solution over the java -jar Application.jar alternative, because this one requires that you setup the classpath inside the jars manifest. So deploying an application that depends on existing libraries on the target system is pretty difficults, just because you have to know the library paths before you build the application.
Setting the classpath (using -cp) is the best way, as you can have a different classpath for each application. The CLASSPATH environment variable is global for all Java applications running on the machine, as is the extension mechanism so you probably don't want to use those.
If your code is executable (ie it has a public static void main(String[] args) method) then you can also specify the class that the main method is in, and the associated classpath within the manifest file inside the Jar file. Once you have done that you can do this:
java -jar myJar.jar
And Java will work out the rest.