| I asked on the geoserver-users/wildfly-users list last week and got some responses to start looking into rights but that didn't turn out to be the problem. Turned on TRACE for almost everything and got no permission problems anywhere. At last setup a develop environment, installed the latest tomcat, wildfly-8.2.1 and wildfly-10.1.0 and deployed geoserver-2.9.2.war from geoserver.org. Problem exists only in Wildfly. Did some debugging and found that the problem is in ManifestLoader.java, to be precise in public static AboutModel getVersions() where we find the following line: Manifest manifest = manifests.get(geoserverPath); The problem is in the file spec which starts with 'vfs:' when geoserver.war is deployed on Wildfly and starts with 'file:' when deployed on Tomcat/Eclipse/Jetty. The call to manifests.get() doesn't allow a virtualfilesystem. Looking around the internet I found a piece of code that circumvents this problem by accepting a class and then loading the manifest irrespective of which filesystem spec is used. Warning: I know enough java to be dangerous ![]() I added the following code: {{ public static Manifest getManifest(Class<?> clz) { String resource = "/" + clz.getName().replace(".", "/") + ".class"; String fullPath = clz.getResource(resource).toString(); String archivePath = fullPath.substring(0, fullPath.length() - resource.length()); if (archivePath.endsWith("\\WEB-INF classes") || archivePath.endsWith("/WEB-INF/classes")) { archivePath = archivePath.substring(0, archivePath.length() - "/WEB-INF/classes".length()); // Required for wars } try (InputStream input = new URL(archivePath + "/META-INF/MANIFEST.MF").openStream()) { return new Manifest(input); } catch (Exception e) { throw new RuntimeException("Loading MANIFEST for class " + clz + " failed!", e); } } }} And changed the line: Manifest manifest = manifests.get(geoserverPath); to: Class geoserver_class = GeoServer.class; Manifest manifest = ManifestLoader.getManifest(geoserver_class); Did that 2 more times. Compiled and deployed to Wildfly/Tomcat and tested whether the REST api call /rest/about/version returned the correct output which it did. Previously it would only return the version info for the three components when deployed on Tomcat. I hope someone is willing to clean this up alot and accept it into master. A grateful geoserver user, Joop |