We are generally accustomed to using MAVEN to manage and compile projects and rarely build a MAVEN environment on the server when deployed. When you deploy a project, you need to add a lot of dependencies and hundreds of jar packages to the project's library.
In general, we will think of adding the jar package to the Classpath directory, as follows:
1, go to the directory of the configuration file: cd etc
[Root@db etc]# VI Profile
2. If you have already configured the Java environment, locate the code block:
java_home=/usr/java/jdk1.8.0_45
export hadoop_prefix=/usr/local/hadoop
path= $JAVA _home/bin: $PATH: $ Hadoop_prefix/bin
classpath=.: $JAVA _home/lib/dt.jar: $JAVA _home/lib/tools.jar
export Java_home
Export PATH
export CLASSPATH
export ld_library_path= $HADOOP _home/lib/native/
3. Add jar packages after classpath.
Classpath=.: $JAVA _home/lib/dt.jar: $JAVA _home/lib/tools.jar:xxxx1.jar:xxxx2.jar
Analysis, such a configuration method is equivalent to write the parameters in the program to die, once the jar package changes, you have to reconfigure, very inflexible.
Recently found a post on stack overflow: CLASSPATH vs Java.ext.dirs http://stackoverflow.com/questions/5039862/ Classpath-vs-java-ext-dirs
One difference is so if we specify our libraries under The-djava.ext.dirs flag, they would be loaded using the extension ClassLoader (e.g Sun.misc.Launcher.ExtClassLoader) instead of the system classloader (e.g. Sun.misc.Launcher.AppClassLoader). Assuming, we have a class named Lib. And our application runs this code:public class main {public static void main (String args[]) {SYSTEM.OUT.P
Rintln (System.getproperty ("Java.ext.dirs"));
ClassLoader test_cl = Main.class.getClassLoader ();
ClassLoader lib_cl = Lib.class.getClassLoader ();
System.out.println (TEST_CL = = LIB_CL);
System.out.println (TEST_CL);
System.out.println (LIB_CL); }} The console output would be:c:\program Files\java\jdk1.6.0\jre\lib\ext; C:\WINDOWS\Sun\Java\lib\ext true sun.misc.launcher$appclassloader@107077e sun.misc.launcher$ appclassloader@107077e when the application is run using the command JAVA-CP "folder/*;."
Main. However, when the APplication is run using the command Java-djava.ext.dirs=folder Main and then the output would instead be:folder false sun.m Isc. launcher$appclassloader@107077e SUN.MISC.LAUNCHER$EXTCLASSLOADER@7CED01
Summary workaround: Java provides us with an extended jar package parameter configuration parameters: Java.ext.dirs
1. Use MAVEN to export all the dependent jar packages, please refer to the previous article:
http://blog.csdn.net/wzygis/article/details/48735133 MAVEN export project-dependent JAR packages
2, the dependent jar package uploaded to the server, put in a directory, such as: dependencies
Java -djava.ext.dirs=/usr/local/dependency xx. Start
Xx. Start is the class where the project's main method resides.
3, another way is to configure environment variables.
Set environment variable name lib variable value c:\java\axis-1_1\lib
Java -djava.ext.dirs=%lib% xx. Start
4. You can set the startup Main method in Maven to start the class.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId> maven-jar-plugin</artifactid>
<version>2.4</version>
<configuration>
< archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix> Lib/</classpathprefix>
<mainClass>com.mobile263.cloudsimcdr.console.Start</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
With reference articles, easy to understand:
If U is in a hurry to compile code and there is a big list of jars files to include in the classpath, there U don t O struggle to include the names of the "the" the jar ' s in the classpath.
There is a neat trick-use the ' java.ext.dirs ' JVM param to the directory containing the jar files.
Java-djava.ext.dirs = c: \ java \ axis-1_1 \ Lib-classpath Classes Myjavaclass
Or set the environment variable VARIABL E name Lib
Variable c: \ java \ axis-1_1 \ lib
java-djava.ext.dirs =% lib%-classpath Classes Myjavaclass