1

For a webservice client I'd like to use Implementation-Title and Implementation-Version from the jar file as user-agent string. The question is how to read the jar's manifest.

This question has been asked multiple times, however the answer seems not applicable for me. (e.g. Reading my own Jar's Manifest)

The problem is that simply reading /META-INF/MANIFEST.MF almost always gives wrong results. In my case, it would almost always refer to JBoss.

The solution proposed in https://stackoverflow.com/a/1273196/4222206 is problematic for me as you'd have to hardcode the library name to stop the iteration, and then still it may mean two versions of the same library are on the classpath and you just return the first - not necessarily the right - hit.

The solution in https://stackoverflow.com/a/1273432/4222206 seems to work with jar:// urls only which completely fails within JBoss where the application classloader produces vfs:// urls.

Is there a way for code in a class to find it's own manifest?

I tried the abovementioned items which seem to run well in small applications run from the java command line but then I'd like to have a portable solution as I cannot predict where my library would be used later.

public static Manifest getManifest() {
    log.debug("getManifest()");
    synchronized(Version.class) {
        if(manifest==null) {
            try {
                // this works wrongly in JBoss
                //ClassLoader cl = Version.class.getProtectionDomain().getClassLoader();
                //log.debug("found classloader={}", cl);
                //URL manifesturl = cl.getResource("/META-INF/MANIFEST.MF");

                URL jar = Version.class.getProtectionDomain().getCodeSource().getLocation();
                log.debug("Class loaded from {}", jar);

                URL manifesturl = null;
                switch(jar.getProtocol()) {
                    case "file":
                        manifesturl = new URL(jar.toString()+"META-INF/MANIFEST.MF");
                        break;
                    default:
                        manifesturl = new URL(jar.toString()+"!/META-INF/MANIFEST.MF");
                }


                log.debug("Expecting manifest at {}", manifesturl);
                manifest = new Manifest(manifesturl.openStream());
            }
            catch(Exception e) {
                log.info("Could not read version", e);
            }
        }
    }

The code will detect the correct jar path. I assumed by modifying the url to point to the manifest would give the required result however I get this:

Class loaded from vfs:/C:/Users/user/Documents/JavaLibs/wildfly-18.0.0.Final/bin/content/webapp.war/WEB-INF/lib/library-1.0-18.jar
Expecting manifest at vfs:/C:/Users/user/Documents/JavaLibs/wildfly-18.0.0.Final/bin/content/webapp.war/WEB-INF/lib/library-1.0-18.jar!/META-INF/MANIFEST.MF
Could not read version: java.io.FileNotFoundException: C:\Users\hiran\Documents\JavaLibs\wildfly-18.0.0.Final\standalone\tmp\vfs\temp\tempfc75b13f07296e98\content-e4d5ca96cbe6b35e\WEB-INF\lib\library-1.0-18.jar!\META-INF\MANIFEST.MF (The system cannot find the path specified)

I checked that path and it seems even the first URL to the jar (obtained via Version.class.getProtectionDomain().getCodeSource().getLocation() ) was wrong already. It should have been C:\Users\user\Documents\JavaLibs\wildfly-18.0.0.Final\standalone\tmp\vfs\temp\tempfc75b13f07296e98\content-e4d5ca96cbe6b35e\WEB-INF\lib\library-1.0.18.jar.

So this could even point to a problem in Wildfly?

Queeg
  • 7,748
  • 1
  • 16
  • 42
  • What if your code is in a `.jar` that's in a `.war`? How about a `.jar` that's in a `.war` that's in a `.ear`? What if it's in a server that isn't Wildfly so there is a totally different class loading setup or isn't in a `.jar` at all? I've used the [git-commit-id-plugin](https://github.com/git-commit-id/maven-git-commit-id-plugin) to do something similar. – stdunbar Nov 08 '19 at 21:41
  • If your suggested scenarios can all be problematic, what is the function class.getProtectionDomain().getCodeSource().getLocation(); then meant to return? Somehow I believe there is a bug in it's implementation as I'd expect it to point to the source where the class was loaded from, not some other path. Is this a misunderstanding on my side or a buggy behaviour on Wildfly? Nevertheless I'll have a closer look at your plugin. Thanks for sharing. :-) – Queeg Nov 11 '19 at 03:17

1 Answers1

1

It seems I found some suitable solution here: https://stackoverflow.com/a/37325538/4222206

So in the end this code can display the correct version of the jar (at least) in JBoss:

this.getClass().getPackage().getImplementationTitle();
this.getClass().getPackage().getImplementationVersion();

Hopefully I will find this answer when I search next time...

Queeg
  • 7,748
  • 1
  • 16
  • 42