| Summary: | PluginTransformer fails to read plug-in version from MANIFEST.MF because MANIFEST.MF is not the first file in the META-INF directory | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | bkramer <bkramer> | ||||||
| Component: | Plugins | Assignee: | Charles Crouch <ccrouch> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 3.0.1 | CC: | ccrouch, hbrock, ldimaggi, loleary | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 705091 726145 769967 (view as bug list) | Environment: |
JON 2.4.1
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode)
|
||||||
| Last Closed: | 2013-09-03 16:59:51 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 725852, 705091, 753929 | ||||||||
| Attachments: |
|
||||||||
|
Description
bkramer
2011-03-04 07:59:12 UTC
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. |