Weblogic - 为什么 Java ClassLoader 不从空清单 jar 中提到的 jars 加载类

Question

I have recently come across of a scenario where we would have a empty manifest jar (ie jar with just META-INF/MANIFEST.MF having Class-Path attribute) referring to other jar file somewhere on file system. I believe this manifest jar has been created to act like a soft link to a specific version jar so that consumer need not deal with minor version changes of implementing jar.

manifest.jar:-
----META-INF/
--------MANIFEST.MF

Actual version specific implementation jar (test-1.1.jar):-
----META-INF/
--------MANIFEST.MF
----test/
--------Test1.class

Including manifest.jar in classpath in application does not load actual implementing jar and hence I see ClassNotFoundException. Any idea why it does not load and how can I get this jar loaded as expected?

Update :
I tried this with a sample executable jar and it (sun.misc.Launcher$AppClassLoader) seems to load the class as expected. Referring just manifest.jar in Class-Path in-turn includes the actual implementing jar.
Also, I found that we do have a legacy custom class loader for the project, not sure if that causing this weird behavior.

By default, shouldn't it take care of the referencing of other jars from manifest.jar?
Is there a way to check whether this custom class loader is actually referencing jars mentioned in Class-Path?

Answer 1

When using java -jar somejar.jar , then the classpath is set up as follows:

• Environment variable CLASSPATH is entirely ignored .
• The -cp / -classpath switch is entirely ignored .
• The Class-Path entry in the manifest of the jar you specified explicitly , ie somejar.jar is read, split on spaces, any relative paths are resolved relative to the directory the jar is in, and that is used as classpath.
• The Class-Path entry in any other jar file, including jar files listed in the Class-Path entry of somejar.jar is entirely ignored .
• The Main-Class entry in the manifest of somejar.jar is read, the string found there is loaded as class, and its main method is invoked. Any Main-Class entries in any jars you mentioned in the Class-Path entry is entirely ignored .

In other words, this proxy concept cannot really work. The jar you put in java -jar thejar.jar must have the Main-Class attribute and must list all the required jars to run that application in its Class-Path attribute.

If you use this instead: java -cp somejar.jar:lib/dep1.jar:lib/dep2.jar:etc com.foo.Main , then the manifest is entirely ignored , and thus whatever you set up in any manifest's Class-Path or Main-Class attribute is irrelevant here.

Answer 2

I think what you are observing may be explained by the JAR file spec section on the Class-Path attribute .

Specifically:

"Currently, the URLs must be relative to the code base of the JAR file for security reasons. Thus, remote optional packages will originate from the same code base as the application."

"Each relative URL is resolved against the code base that the containing application or library was loaded from. If the resulting URL is invalid or refers to a resource that cannot be found then it is ignored."

So, if the Class-Path attribute in the MANIFEST.MF file for manifest.jar uses absolute URLs, or URLs starting with "/", or if they do not resolve relative to the location of manifest.jar itself, the corresponding JARs, etc won't be added to the internal classpath. They are silently ignored.

This would happen if you just copied the manifest.jar into your project...