Bug 907713
Summary: | Invalid OSGi version format for module ch.qos.cal10n | ||
---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Osamu Nagano <onagano> |
Component: | OSGi | Assignee: | Thomas Diesler <thomas.diesler> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.0.1 | CC: | bmaxwell, daniel.chapman, fedora-bugzilla-odin, onagano, thomas.diesler |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-24 23:23:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Osamu Nagano
2013-02-05 05:42:02 UTC
For Me EAP 6.1 final, JBoss OSGi 2.1.0 08:55:14,820 INFO [org.jboss.as] (MSC service thread 1-7) JBAS015899: JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) starting 08:55:18,955 INFO [org.jboss.osgi.framework] (MSC service thread 1-10) JBOSGI011006: OSGi Framework - 2.1.0.Final-redhat-1 08:55:19,206 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC000001: Failed to start service jbosgi.BootstrapBundles.INSTALL: org.jboss.msc.service.StartException in service jbosgi.BootstrapBundles.INSTALL: JBAS011955: Failed to process initial capabilities at org.jboss.as.osgi.service.BootstrapBundlesIntegration.start(BootstrapBundlesIntegration.java:160) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] Caused by: java.lang.NumberFormatException: For input string: "2-redhat-4" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_25] at java.lang.Integer.parseInt(Integer.java:492) [rt.jar:1.7.0_25] at java.lang.Integer.parseInt(Integer.java:527) [rt.jar:1.7.0_25] at org.osgi.framework.Version.<init>(Version.java:133) at org.osgi.framework.Version.parseVersion(Version.java:218) at org.jboss.osgi.metadata.spi.AbstractOSGiMetaData.toString(AbstractOSGiMetaData.java:291) at org.jboss.osgi.resolver.spi.AbstractResourceBuilder.loadFrom(AbstractResourceBuilder.java:226) at org.jboss.as.osgi.service.BootstrapBundlesIntegration.installInitialModuleCapability(BootstrapBundlesIntegration.java:203) at org.jboss.as.osgi.service.BootstrapBundlesIntegration.start(BootstrapBundlesIntegration.java:149) ... 5 more For me this was coming from joda-time version "1.6.2-redhat-4" but I'm sure once this is fixed the next problem module will make itself visible. Time to write a utility to repack the OSGi broken JARs provided. Can we not just remove the OSGi subsystem/tests? It has been removed in wildlfy already. Hmm... how about running and checking the OSGi subsystem tests as a GA release has been spun but before allowing it to be released to the public? This is the real failure here, the failure to verify (and document) which satellite (not provided in the AS distribution ZIP) JBoss modules are compatible with the final GA release. I'm sure it would have detected with better release engineering processes. From what I understand here the META-INF/MANIFEST.MF of the provided modules (in the AS distribution ZIPs in modules/** dir) attempts to provide OSGi metadata, but this metadata does not conform to OSGi specification. For example the Version field is incorrectly formatted. Maybe an additional unit test should be performed on all release engineering, to validate the MANIFEST.MF of every JAR (or exploded JAR) confirms to all specifications (J2SE, OSGi, JBoss Modules). Also that resolution or every bundle is possible (because what it depends on it provided or expected by JRE/JDK). I have seen this problem too with JBossAS distirbutions. The problem is that EAP6.1-alpha and EAP6.1-beta and WindFly-*-alpha* do not have this problem. Since they do no suffix the version with "-redhat-4" they use the normal version of the open source JAR. Only the GA releases have this problem because in order to make concrete the exact version (for long term support purposes) every module is given a version suffix like "-redhat-4". But this is added in a way that breaks OSGi version semantics. 1.2.3-redhat-4 is invalid. 1.2.3.4-redhat-4 is valid, so is 1.2.3.redhat-4 is also valid. To verify this download EAP-6.1-beta and WildFly-8.0.0-Alpha4 and take a look at the modules/**/joda-time*jar file and the MANIFEST.MF inside. Now take a GA release such as EAP6.1 and take a look at the MANIFEST.MF in there. This is a release engineering issue, concerning the process to roll a GA release of the whole AS and provide versioned JAR to be able to allow redhat to provide long-term support to customers. Integration and integrity tests of the GA release are needed to verify the resulting distribution. Yes, if the productization touches the osgi meta data it must do it according to the standard. As a side note: some bundles embed other jars. Has this been addressed properly? The Bundle-Classpath must be handled properly without changing the isolation semantics. Closing, workaround modify the MANIFEST.MF. Also OSGI was Tech Preview and it is now not going to be fully supported as per: https://access.redhat.com/solutions/362814 |