I am trying to install log4j (2) on Windows 10. I downloaded and extracted log4j from https://logging.apache.org/log4j/1.2/download.html
However I don't know what do add to the path variable or how to call log4j on windows 10.
The latest steps on Linux for log4j where:
$ export CLASSPATH=$CLASSPATH:/usr/local/apache-log4j-1.2.15/log4j-1.2.15.jar
$ export PATH=$PATH:/usr/local/apache-log4j-1.2.15/
The Problem here is, as far as I know, Windows has no classpath and there is no log4j.jar file just log4j-core and log4j-api (and similar) jars.
If someone could help me set this up correctly I'd greatly appreciate this.
Log4j does not require installation. It is a set of libraries. You should not specify the CLASSPATH as a system-wide environment variable (however it is acceptable). If you want your application make use of log4j you should propagate the class path to log4j libraries as a parameter to java.exe. If you need those libs on development phase you should either specify the path in your IDE project settings (the way how to do this is specific for each particular IDE), or, if you use standard maven project type, specify the appropriate dependency in pom file so that IDE takes care of proper classpath configuration.
Please also refer to this post helping you to get started with log4j.
Related
The Spring Boot Maven and Gradle plugins can now generate full executable archives for Linux/Unix operating systems.Running a fully executable JAR is as easy as typing:
$ ./myapp.jar
My question is in this case how to set -D properties, e.g.
-Dspring.profiles.active=test
In addition, if server does not install jdk , could this fully executable jar still run?
There are two ways to configure properties like that:
1:
By specifying them in a separate configuration file. Spring Boot will look for a file named like JARfilename.conf which should be stored in the same folder like the JAR file. There you can add the environment variable JAVA_OPTS:
JAVA_OPTS="-Dpropertykey=propvalue"
2:
Or you can just specify the value for the environment variable in the shell before you execute the application:
JAVA_OPTS="-Dpropertykey=propvalue" ./myapp.jar
Have a look at the documentation for the complete list of available variables: http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#deployment-service
Regarding your second question: To execute a JAR, you don't need a JDK, a JRE is sufficient (but you need at least that, if you don't have any java installed on the server, the application won't run).
By default SpringApplication will convert any command line option arguments (starting with ‘--’, e.g. --server.port=9000) to a property and add it to the Spring Environment. As mentioned above, command line properties always take precedence over other property sources.
e.g.
$ java -jar myapp.jar --spring.application.json='{"foo":"bar"}'
please see http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/
I want specify the Java home path during building my Android gradle via command line; for example,
gradle build -d path of jdk
Is it possible?
According to gradle documentation:
The following properties can be used to configure the Gradle build
environment:
...
org.gradle.java.home Specifies the Java home for the Gradle build
process. The value can be set to either a jdk or jre location,
however, depending on what your build does, jdk is safer. A reasonable
default is used if the setting is unspecified.
org.gradle.jvmargs Specifies the jvmargs used for the daemon process.
The setting is particularly useful for tweaking memory settings. At
the moment the default settings are pretty generous with regards to
memory.
In other words, you can do it simply by running
gradle build -Dorg.gradle.java.home=<java home path>
Depending on what you want to accomplish, one of the following should work.
As Amnon Shochot suggested, set the -Dorg.gradle.java.home flag. This is probably preferable in most cases.
If you want to have use a particular JDK throughout, set the JAVA_HOME variable appropriately before executing gradle.
$ export JAVA_HOME=/usr/local/specialJava/
$ gradle build
If you don't want to change the environment, try adding the below to your build.gradle script. It should affect only the compiler used to compile Java code, nothing else. So Gradle doesn't run inside this particular JDK, but it will use it for compiling.
tasks.withType(JavaCompile) {
options.fork = true
options.forkOptions.executable = "/usr/local/specialJava/bin/javac"
}
(Last option stolen from here)
I'm having issues with a test, which when executed in maven fails to initialize log4j, although a valid log4j.properties is in src/test/resources and therefore should end up on the classpath of the test. But it doesn't, i.e. log4j prints only
log4j:WARN No appenders could be found for logger (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
log4j:WARN Please initialize the log4j system properly.
In order to debug the problem I printed the classpath from the test itself, using the code here
But instead of a lengthy list of jars and paths I just get
/<projectpath>/target/surefire/surefirebooter6226797341642271676.jar
So my questions are:
WTF is maven doing with the classpath?
Why doesn't my log4j.properties end up on the classpath?
How do I debug this?
Note: In Eclipse I can run the test just fine and everything works as expected.
Another note: the maven project is a multimodule project and I'm only executing a single test from a single submodule, with a commandline like this:
mvn -U -Dtest=de.company.project.SomeTest clean test
Have a good look at the maven-surefire-plugin. By default it creates a jar stuffed with your entire classpath. This is controlled by the useManifestOnlyJar option. This works around the problem of Windows having a classpath limit of 1024 (quoting off the top of my head). Under Linux you wouldn't really feel this pain much as the limit is much higher.
If you are forking the maven-surefire-plugin, it will use a different classpath than the one you're running Maven (and the compilation).
Debugging this kind of crappy situation can be done as follows:
In one of your tests add a loop that lists all the environment variables along with the java system properties.
Debug the tests:
mvn -Dmaven.surefire.debug="-Xdebug \
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9001 \
-Xnoagent" \
test
I found the answer to question 1.
Maven creates the jar with the weird name on the fly and just puts a MANIFEST.MF file in there. That file contains the classpath, and the main class to be started.
This also answers to some extend question 3.
You can copy that jar file somewhere else, while maven is running, so it does not delete it once it is finished. Then you can examine it as long as you want. Turns out my log4.properties is on the classpath (the target directories for the testclasses is there and the properties files is in that directory ....)
Leaves me with question 2.
It turned out somewhere in the forest of pom.xmls the system property log4j.configuration was set to a rather useless value. Setting that value back to the propervalue as described here solved my immediate problem.
Now I just have to find the broken spot in our poms, but that's a story for a different day.
I have installed a third party java webservice which uses Oralce jdbc thin driver to write data into Oracle database. When i run this, i get the following error;
JDBC Driver class not found: oracle.jdbc.OracleDriver
I have oracle installed and set classpath variable to following value:
*D:\oracle\product\10.2.0\client_1\jdbc\lib\classes12.jar;D:\oracle\product\10.2.0\client_1\jdbc\lib\classes12.zip;D:\oracle\product\10.2.0\client_1\jdbc\lib\ojdbc14.jar;D:\oracle\product\10.2.0\client_1\jdbc\lib\ojdbc14.zip;C:\Program Files\Java\jdk1.7.0\jre\lib\rt.jar*
and path variable to following value;
*D:\oracle\product\10.2.0\client_1\bin;C:\Program Files\Java\jdk1.7.0\bin\;D:\oracle\product\10.2.0\client_1\jdbc\lib\classes12.jar;D:\oracle\product\10.2.0\client_1\jdbc\lib\classes12.zip;D:\oracle\product\10.2.0\client_1\jdbc\lib\ojdbc14.jar;D:\oracle\product\10.2.0\client_1\jdbc\lib\ojdbc14.zip*
Any suggestion why web service is not able to identify jdbc driver?
Thanks
I know 2 ways of turning Java app into Windows service and both do not use CLASSPATH. One is Java Service Wrapper by Tanuki Software. This tool uses wrapper.conf where you can show directories with .jar libraries:
# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
wrapper.java.classpath.1=c:\jars\*
wrapper.java.classpath.2=myservice.jar
Second tool I know is JSL: Java Service Launcher. In this tool there is jsl.ini where you put command line to run your server. It can use java with -cp option to show location of .jar libraries:
[defines]
MY_LIBS=d:\jars\*
AXIS_LIBS=d:\axis2-1.5.4\lib\*
CLASSPATH=.;%MY_LIBS%;%AXIS_LIBS%
export = CLASSPATH
...
[java]
...
cmdline = -Dfile.encoding=utf8 -cp %CLASSPATH% example.my.server
In both configuration you can use * to add all .jar files or you can show those files one by one (just like in CLASSPATH).
At first you should know what Windows is trying to execute. Check it in the service properties page. Then try to localize its configuration. If it uses one of tools I know then you know what to change. Other tools probably have similar configuration.
Method 1:
Download ojdbc.jar
add ojdbc6.jar to deployment assembly.
Right click on project->properties->select deployment assembly->click on 'Add'
->select 'Archives from File System'->browse to the folder where ojdbc6.jar is saved.->add the jar->click finish->Apply/OK.
Method 2:
if you want to add ojdbc.jar to your maven dependencies you follow this link:
http://www.mkyong.com/maven/how-to-add-oracle-jdbc-driver-in-your-maven-local-repository/
.
.
Even if you're using a maven project it is not necessary to add ojdbc to maven dependencies(method 2), method 1 (adding directly to deployment assembly) works just fine.
Make sure you have the ojdbc jar file (make sure you are using the correct one because depending on java version you may need to choose a different one).
use ojdbc14.jar for Java 1.4
use ojdbc5.jar for Java 1.5
ojdbc6.jar for Java 1.6
here is linke where you can download ojdbc6.jar file
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html
You also have to add the jdbc jar to your server classpath. if tomcat, rigth-click on your Project->run as->run configurations, click on classpath and add your jdbc jar in Add external jars option
add ojdbc-6.jar to your lib directory of tomcat installation. Maven will downlowd this jar for you in .m2 directory, but you need to have this jar in tomcat lib as well.
My work project needs to be compiled and run under JDK1.5 and I'm on a Mac. I followed the instructions here to get 1.5 back on Snow Leopard, and it works fine when building from IntelliJ IDEA, or if I'm just in the same directory as the build.xml and try "ant CleanRebuild" When I "Run Target" in NetBeans they're all compiled with the wrong version resulting in
java.lang.UnsupportedClassVersionError:
Bad version number in .class file
(unable to load class...
when tomcat is trying to start up.
So things I've tried
Set the "Java Platform" to 1.5 under the project properties/libraries.
Set the Source/Binary Format to JDK 5 under project properties/sources.
Pointed the ant home to the ant I'm using under preferences/ant
Renaming every javac executable I could find in the hopes NetBeans would fail to compile and I could figure out which one it was using (no luck)
Setting 1.5 as the default, resulting in the need to point $netbeans_jdkhome to the 1.6 jdk in order for NetBeans to even start.
All unsuccessful....
Again, if I cd into the directory of the netbeans project with the build.xml and run the command manually all is well....so NetBeans. What's the deal?
Revised answer
Assumptions: NetBeans version 6.9.1 (although likely applicable to most or all 6.x versions), alternative build systems (e.g., Maven) are not used...the default (Ant) is used.
NetBeans, by default, uses Ant as its build system for doing things like compiling a project, building a project, cleaning built files from a project, etc. Ant has two concepts that are applicable here: targets and tasks. A target, in Ant's vocabulary, is simply a "command" or a series of jobs that need to be completed for a particular job. In NetBeans, common targets are "Compile", "Build", "Clean and Build", etc. The "jobs" that a target completes are (among other things) Ant tasks. In NetBeans one task (which is particularly relevant in answering this question) is the Javac Task. This is the task that Ant uses to compile .java files into .class files.
An Ant-based project, and therefore a NetBeans project, uses the file build.xml to control the build process and tell Ant how to go about accomplishing the targets. In a NetBeans project, the build.xml is found in the root directory of the project, by default. NetBeans, however, uses a user-extensible build.xml file. The core targets and tasks defined by NetBeans are actually located in nbprojects/build-impl.xml and imported into build.xml within the first few lines of the file. The theory is that users can add or override things in build.xml while the core NetBeans-defined configuration remains untouched in the build-impl.xml file.
If you look in the default nbproject/build-impl.xml file for a NetBeans Java project, you will find the Javac task referred to twice. (Search for "<javac".) Both are in macro definitions, and therefore deep within the complexities of NetBean's default build configuration. If we refer to the Javac Task documentation we find that the tasks uses the compiler in the location specified either by the global build.compiler property, by the compiler attribute specified with the <javac... /> task, or the default which is the Java compiler that is used when running and, and thus the one that is used when running NetBeans (because it is what fires off the Ant process). Since we don't see build.compiler or the compiler attribute anywhere (in the default build-impl.xml), then we can only conclude that the default is being used.
So here we have the (more-or-less correct) first answer. NetBeans compiles using the JDK that was used to execute NetBeans by default. It looks like it is actually a bit more complicated than that simple answer, but it is essentially correct. If you look at the documentation for the Javac Task it alludes to "a class that implements the CompilerAdapter interface", which suggests that rather than calling the javac executable directly, Ant (and therefore NetBeans) compiles using the compiler class (that, in all likelihood, the javac executable also uses). Refer to the Original answer below to determine which JDK what used to run NetBeans.
So, what if you don't want to use the default JDK that was used to run NetBeans? This is where "Java Platforms" comes in. Go to the Tools menu, and click on "Java Platforms". You likely only have one platform defined here. (As an aside, this is actually the most correct answer to what JDK is used by default... the one defined here in the Java Platform Manager.) If you would like to compile against another Java version (say your default JDK is 1.6, but you want to compile against 1.5) then you would install the alternate JDK somewhere on your system, and then configure a platform here in NetBeans' Java Platform Manager. (I'll leave it as an exercise for you to find the documentation on how to add a Java Platform. A superficial search of the wiki didn't turn up anything obvious. In any case, it's fairly self-explanatory.)
Once a new platform is created in the manager, you would right-click on your project in the Projects tab, click on "Properties", and then on "Libraries". At the top, you would select the appropriate Java platform for the project. As soon as you change this value and click on "OK", NetBeans makes several adjustments to your build-impl.xml file that point it to the new JDK against which to compile. (It is instructive for the truly geeky amongst us to make a copy of the nbproject directory before making this change and to diff that against the new contents of the nbproject directory after the change is made.) The changes instruct the Javac Ant Task to use the (equivalent of the) javac executable of the specified platform. So here we have the most correct answer: NetBeans uses the equivalent of the javac executable (as invoked by the Ant javac task) that is specified in the project's Java Platform located under the Libraries node of the project's properties.
Original answer
The path to the JDK used by NetBeans can be found in the netbeans.conf file. Look for the netbeans_jdkhome entry.
You can also specify the jdkhome at runtime (*NIX example given):
netbeans --jdkhome /usr/bin/jdk1.6.0_22
The netbeans.conf file is found in different places depending on what OS you are using. See the NetBeans.conf FAQ on the NetBeans wiki for help finding the file.
A few additional comments...
...You can specify the -target option in the project properties. In NetBeans 6.9 right-click on the project, and choose Properties. Click on the Compiling node. Add your -target to Additional Compiler Options.
...I have read in a few places that specifying a target is not a guarantee that the code will run on a JRE whose version is lower than the JDK that built it. In other words, the recommendation seems to be that if you want 1.5 binaries, then compile with the 1.5 JDK.