Foreword:
Recently, I encountered a pit about the jar package, and I almost missed it. If it feels interesting, I will record it.
one,
antecedent
There is a small project, which is developed by springboot, has a connection database, and the database uses postgresql.
There is nothing to say about deployment. You must first run the project in the front desk of the Java -jar jar package, and then debug according to the error report.
OK, according to the log printed at the front desk, I found that the database connection IP was wrongly written. There is nothing to say about this. Find an empty directory, decompress it, modify the configuration of the database, and repackage it into a jar package
But. . . . But yes. . . . . The jar package reported an error directly, probably this is the error report (just found a jar package to demonstrate)
[root@node1 media]# java -jar ojdbc14.jar
no main manifest attribute, in ojdbc14.jar
OK, the command to decompress and repackage is like this, the manifest file has not been touched, it is very strange:
jar -xf jar包名称
jar cvf jar包名称 *two,
Troubleshooting
Still take this ojdbc jar package as an example, observe the contents of its MANIFEST.MF file before and after packaging
Before packaging, that is, after decompression:
[root@node1 META-INF]# cat MANIFEST.MF
Manifest-Version: 1.0
Specification-Title: Oracle JDBC driver classes for use with JDK14
Sealed: true
Created-By: 1.4.2_08 (Sun Microsystems Inc.)
Implementation-Title: ojdbc14.jar
Specification-Vendor: Oracle Corporation
Specification-Version: Oracle JDBC Driver version - "10.2.0.1.0XE"
Implementation-Version: Oracle JDBC Driver version - "10.2.0.1.0XE"
Implementation-Vendor: Oracle Corporation
Implementation-Time: Wed Jan 25 01:28:31 2006
Name: oracle/sql/converter/
Sealed: false
Name: oracle/sql/
Sealed: false
Name: oracle/sql/converter_xcharset/
Sealed: false
After packaging:
Manifest-Version: 1.0
Created-By: 1.8.0_271 (Oracle Corporation)
OK, this shows that the way of packaging is wrong, and some parameters are missing, which leads to changes in the MANIFEST.MF file, which in turn makes the package unusable
three,
solution
Correct packing posture:
First look at the help of the jar command:
[root@node1 media]# jar --help
Illegal option: -
Usage: jar {ctxui}[vfmn0PMe] [jar-file] [manifest-file] [entry-point] [-C dir] files ...
Options:
-c create new archive
-t list table of contents for archive
-x extract named (or all) files from archive
-u update existing archive
-v generate verbose output on standard output
-f specify archive file name
-m include manifest information from specified manifest file
-n perform Pack200 normalization after creating a new archive
-e specify application entry point for stand-alone application
bundled into an executable jar file
-0 store only; use no ZIP compression
-P preserve leading '/' (absolute path) and ".." (parent directory) components from file names
-M do not create a manifest file for the entries
-i generate index information for the specified jar files
-C change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name, the archive file name and the entry point name are
specified in the same order as the 'm', 'f' and 'e' flags.
OK, the -M parameter specifically mentions not to modify MANIFEST.MF, and a key parameter -0 does not use compression (compression operations sometimes cause unpredictable problems, in human terms, compression is unstable)
Then, the correct packaging command is:
jar cvM0f jar包名 *After changing the packaging posture, the jar package runs correctly, and the configuration is found to be effective, pointing to the correct database, everything is perfect~~~~! ! ! !
summary:
Sometimes it is still not serious enough. In fact, if you look at the command help first, you will not fall into the pit.