This issue is caused by calling getManifest() from JarInputStream which is a long running Sun JVM bug identified in:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4338238
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5046178
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4696354


From the looks of it, the implementation requires the MANIFEST.MF file to be the first entry in META-INF. All the JARs which trigger the error message have been packaged with the MANIFEST.MF falling later in the META-INF directory. This seems like a packaging issue.

Archive:  jopr-jboss-as-5-plugin-3.0.1.GA.jar
Archive:  jopr-jboss-as-plugin-3.0.1.GA.jar
Archive:  jopr-jboss-cache-v3-plugin-3.0.1.GA.jar
Archive:  jopr-rhq-server-plugin-3.0.1.GA.jar
Archive:  rhq-ant-bundle-plugin-3.0.1.GA.jar
Archive:  rhq-apache-plugin-3.0.1.GA.jar
Archive:  rhq-augeas-plugin-3.0.1.GA.jar
Archive:  rhq-jmx-plugin-3.0.1.GA.jar
Archive:  rhq-postgres-plugin-3.0.1.GA.jar


The result will be the plug-in container throwing several error messages on initialization as it attempts to get the version information of the plug-ins. Although the plug-ins appear to eventually be loaded, this state means that version information used in determining plug-in version information for the purpose of upgrade/update may fail.

Created attachment 485821 [details]
Possible patch

Created attachment 485963 [details]
Possible patch v2

This version of the patch checks if the url is a file url and then uses a JarFile.
Otherwise the JarInputStream is used so that jndi:/ urls will still work for EmbJopr.

See also https://issues.jboss.org/browse/EMBJOPR-274

I tested the patch in my instance and it does resolve the issue. I can not see any side affects from such a fix either.

Of course, I am guessing that this same exception/error is occurring in EAP admin-console and this patch would not resolve that issue.

Maybe further discussion is necessary?

Yes another bug for the JarInputStream limitation: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4263225

Right, Heiko's patch is not going to clear up the error messages in the admin console, since it only handles the file URL case. I think the best way to go to fix this on the admin console side would be to first try to obtain the manifest via JarInputStream.getManifest(). If getManifest() returns null, then iterate all entries in the jarfile looking for a META-INF/MANIFEST.MF entry; if one is found, then obtain the manifest using "new Manifest(manifestEntryInputStream)". If not, then the jarfile truly does not contain a manifest. In fact, this solution would work for both the RHQ/JON and admin-console sides and so could replace the previous patch.

Fixed in master (commit 5e63bfc) with the following updated impl of PluginTransformer.getVersionFromPluginJarManifest():

private String getVersionFromPluginJarManifest(URL pluginJarUrl) throws IOException {
        JarInputStream jarInputStream = new JarInputStream(pluginJarUrl.openStream());
        Manifest manifest = jarInputStream.getManifest();
        if (manifest == null) {
            // BZ 682116 (ips, 03/25/11): The manifest file is not in the standard place as the 2nd entry of the JAR,
            // but we want to be flexible and support JARs that have a manifest file somewhere else, so scan the entire
            // JAR for one.
            JarEntry jarEntry;
            while((jarEntry = jarInputStream.getNextJarEntry()) != null) {
                if (JarFile.MANIFEST_NAME.equalsIgnoreCase(jarEntry.getName())) {
                    manifest = new Manifest(jarInputStream);
                    break;
                }
            }
        }
        try {
            jarInputStream.close();
        } catch (IOException e) {
            LOG.error("Failed to close plugin jar input stream for plugin jar [" + pluginJarUrl + "].", e);
        }
        if (manifest != null) {
            Attributes attributes = manifest.getMainAttributes();
            return attributes.getValue(Attributes.Name.IMPLEMENTATION_VERSION);
        } else {
            return null;
        }
    }

Fixed in release-3.0.1 (commit 07e8c7b) using the same code applied to master.

Bulk closing of old issues that are in VERIFIED state.