Maison  >  Article  >  Java  >  Le script Shell implémente la méthode d'exécution du programme Java jar

Le script Shell implémente la méthode d'exécution du programme Java jar

黄舟
黄舟original
2017-10-19 09:30:052587parcourir

Cet article présente principalement la méthode d'exécution du programme Java jar via un script shell. L'éditeur pense que c'est assez bon. Maintenant, je vais le partager avec vous et le donner comme référence. Suivons l'éditeur et jetons un coup d'œil

Lors du déploiement de projets sur UBuntu, nous démarrons souvent le programme via un shell, ou même appelons régulièrement le programme java via la tâche planifiée crontab, mais il y a un problème très étrange qui est, par exemple, que j'ai écrit le script shell suivant :


#!/bin/sh
export mypath=/root/project/wishnomal

java -Xmx3000m -Xms3000m -server -d64 -Dfile.encoding=UTF-8 -Dfetch.threads=300 -classpath $mypath/:$mypath/wish2-assembly-1.0.0.jar newstandard.CrawlerNewStandard $*

echo "END"

Lorsque vous exécutez le script manuellement à partir de la ligne de commande, vous pouvez exécuter le programme java normalement, mais utilisez la tâche planifiée crontab, cela semble n'avoir aucun effet

Analyse des raisons possibles :

1) Si l'utilisateur actuel n'a pas les autorisations exécutables pour ce script shell, passez ls -lrt / apps/service/mtk/checking/ Run.sh vérifie que le script est exécutable, mais qu'il dispose de l'autorisation d'exécution - rwxr-xr-x

2) Puisque l'exécution du script seul ne pose pas de problème, est-ce un timing problème? J'ai donc écrit un simple script shell de sortie et cela n'a posé aucun problème de timing. Le problème vient toujours du script.

Plus tard, j'ai vérifié en ligne et j'ai pensé que cela pourrait être la raison des variables d'environnement dans le script, car lors de l'exécution du script via crontab, l'utilisateur root est utilisé à la place de l'utilisateur actuel, donc je cat /etc /profile pour vérifier les variables d'environnement puis les modifier. Le script est le suivant :

Analyse des raisons possibles :

1) Si l'utilisateur actuel n'a pas les autorisations exécutables pour ce script shell. , vérifiez ls -lrt /apps/service/mtk/checking/run.sh Le script est exécutable, mais il a l'autorisation d'exécution -rwxr-xr-x

2) Puisqu'il n'y a aucun problème pour exécuter le script seul, est-ce une question de timing ? J'ai donc écrit un simple script shell de sortie et cela n'a posé aucun problème de timing. Le problème vient toujours du script.

Plus tard, j'ai vérifié en ligne et j'ai pensé que cela pourrait être la raison des variables d'environnement dans le script, car lors de l'exécution du script via crontab, l'utilisateur root est utilisé à la place de l'utilisateur actuel, donc je cat /etc /profile pour vérifier les variables d'environnement puis les modifier. Le script est le suivant :


#!/bin/sh
export mypath=/root/project/wishnomal
export JAVA_HOME=/root/lib/jdk1.7.0_72
PATH=$PATH:$JAVA_HOME/bin

java -Xmx3000m -Xms3000m -server -d64 -Dfile.encoding=UTF-8 -Dfetch.threads=300 -classpath $mypath/:$mypath/wish2-assembly-1.0.0.jar newstandard.CrawlerNewStandard $*

echo "END"

export affiche les variables d'environnement exportées en tant que variables d'environnement utilisateur

De cette façon, les tâches planifiées par crontab seront normales.

Référence de modification :


#!/bin/sh 
# ----------------------------------------------------------------------------- 
# Start script for the CMGP BOSSCONTROL  
# 
# $Id: run_bosscontrol.sh,v 1.0 2007/11/06 Exp $ 
# ----------------------------------------------------------------------------- 
#指定字符集 
LANG=zh_CN.GBK export LANG 
RUN_HOME=. 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/checking.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/ojdbc14.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/commons-dbutils-1.1.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/log4j-1.2.14.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/dom4j-1.6.jar 
 
export CLASSPATH 
 
java com.**.checking.Checking_Start >> log.out &

Lorsque vous exécutez le script manuellement à partir de la ligne de commande, vous pouvez exécuter le programme Java normalement, mais en utilisant crontab programmé tâches, il semble que cela ne fonctionne plus, je suis très déprimé. Vérifiez la raison et analysez les raisons possibles :

1) Si l'utilisateur actuel n'a pas les autorisations exécutables pour ce script shell, utilisez ls -lrt /apps/service/mtk/checking /run.sh montre que le script est exécutable, mais il dispose de l'autorisation d'exécution -rwxr-xr-x

2) Puisqu'il n'y a aucun problème à exécuter le script seul , est-ce un problème de timing ? J'ai donc écrit un simple script shell de sortie et cela n'a posé aucun problème de timing. Le problème vient toujours du script.

Plus tard, j'ai vérifié en ligne et j'ai pensé que cela pourrait être les variables d'environnement dans le script, car lors de l'exécution du script via crontab, l'utilisateur root est utilisé à la place de l'utilisateur actuel, donc je cat /etc/profile pour vérifier les variables d'environnement puis les modifier. Le script est le suivant :


#!/bin/sh 
# ----------------------------------------------------------------------------- 
# Start script for the CMGP BOSSCONTROL  
# 
# $Id: run_bosscontrol.sh,v 1.0 2007/11/06 Exp $ 
# ----------------------------------------------------------------------------- 
export PATH=/apps/usr/java/jdk1.5/bin:$PATH 
export JAVA_HOME=/apps/usr/java/jdk1.5 
export JRE_HOME=/apps/usr/java/jdk1.5/jre 
export CLASSPATH=/apps/usr/java/jdk1.5/lib:/apps/usr/java/jdk1.5/jre/lib:$CLASSPATH 
RUN_HOME=/apps/service/checking 
CLASSPATH=$CLASSPATH$RUN_HOME/lib/checking.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/ojdbc14.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/commons-dbutils-1.1.jar 
CLASSPATH=$CLASSPATH:$RUN_HOME/lib/log4j-1.2.14.jar 
 CLASSPATH=$CLASSPATH:$RUN_HOME/lib/dom4j-1.6.jar 
 
export CLASSPATH=$CLASSPATH 
 
java com.**.checking.Checking_Start >> log.out &

export affiche les variables d'environnement exportées en tant que variables d'environnement utilisateur

Le package jar ci-dessus est exporté via l'outil Eclipse. L'exportation n'inclut pas le fichier MANIFEST.MF Si vous utilisez l'outil d'empaquetage Ant, nous pouvons définir Class-Path


dans le build.xml par défaut. et ajoutez le package jar tiers au fichier manifest.mf, puis spécifiez la classe principale du programme


et ajoutez le contenu suivant dans build.xml :


De plus, lors de la création du fichier manifeste, Ajoutez :
<!-- create a property containing all .jar files, prefix lib/, and seperated with a space --> 
<pathconvert property="libs.project" pathsep=" "> 
  <mapper> 
   <chainedmapper> 
    <!-- remove absolute path --> 
    <flattenmapper /> 
    <!-- add lib/ prefix --> 
    <globmapper from="*" to="lib/*" /> 
   </chainedmapper> 
  </mapper> 
   <path> 
   <!-- lib.home contains all jar files, in several subdirectories --> 
   <fileset dir="${lib.dir}"> 
   <include name="**/*.jar" /> 
   </fileset> 
   </path> 
 </pathconvert>


Exécutez comme ceci, le contenu de MANIFEST.MF dans le package jar résultant est le suivant :
<!-- 这样就可以将第三方jar包加入 -->  
<attribute name="Class-Path" value="${libs.project}" /> 
<!-- 程序运行的主类 --> 
<attribute name="Main-Class" value="com.**.checking.Checking_Start " />


De cette façon, il n'est pas nécessaire de spécifier le package jar requis par le programme dans le script shell, et il n'y a pas de problème ennuyeux de définition des variables d'environnement. C’est ainsi que fonctionnent les plus formels.
Manifest-Version: 1.0 
Ant-Version: Apache Ant 1.7.0 
Created-By: 1.5.0_09-b01 (Sun Microsystems Inc.) 
Implementation-Title: fee task 
Implementation-Version: 1.0 
Implementation-Vendor: Aspire 
Main-Class: com.aspire.cmgp.flowcontrol.server.FlowControlServer 
Class-Path: lib/cmgp-util-1.0.1.jar lib/commons-codec-1.3.jar lib/comm 
 ons-collections.jar lib/commons-dbcp-1.2.1.jar lib/commons-httpclient 
 .jar lib/commons-logging.jar lib/commons-pool-1.2.jar lib/dom4j.jar l 
 ib/log4j.jar lib/ojdbc14.jar


Exécutez simplement le package jar directement dans le shell : java -jar main program.jar -Xmx1024m -Xms1024m -Xmn512m,

Append

source /etc/profile

source ~/.bash_profile

Test. .


java -cp ${CLASSPATH} Le nom du package où se trouve la méthode principale. Le nom de la classe où se trouve la méthode principale

.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn