Bug 907713

Summary: Invalid OSGi version format for module ch.qos.cal10n
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Osamu Nagano <onagano>
Component: OSGiAssignee: Thomas Diesler <thomas.diesler>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0.1CC: 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
Description of problem:
When adding a module 'org.slf4j.ext', which depends on 'ch.qos.cal10n', as an OSGi capability, NumberFormatException rises because the latter's version string doesn't obey the format expected by OSGi spec.


Steps to Reproduce:
1. Edit the standalone.xml to let 'activation' be 'eager' and add 'org.slf4j.ext' capability.
--
        <subsystem xmlns="urn:jboss:domain:osgi:1.2" activation="eager">
            ...
            <capabilities>
                ...
                <capability name="org.slf4j.ext"/>
            </capabilities>
        </subsystem>
--

2. Start up the server then the following stack trace will appear.

  
Actual results:
--
12:33:00,114 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jbosgi.integration.AutoInstallHandler: org
.jboss.msc.service.StartException in service jbosgi.integration.AutoInstallHandler: JBAS011955: Failed to process initial capabilities
        at org.jboss.as.osgi.service.AutoInstallIntegration.start(AutoInstallIntegration.java:190)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.
GA-redhat-2]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat
-2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
Caused by: org.jboss.osgi.resolver.ResourceBuilderException: JBOSGI010908: Cannot initialize resource from: {Export-Package=[org.slf4j.profiler[attr={
version=[1.6.1.redhat-2]},dirs={}], org.slf4j.cal10n[attr={version=[1.6.1.redhat-2]},dirs={}], org.slf4j.ext[attr={version=[1.6.1.redhat-2]},dirs={}]]
, Bundle-SymbolicName=[slf4j.ext[attr={},dirs={}]], Import-Package=[org.slf4j[attr={version=[1.6.1.redhat-2]},dirs={}], org.slf4j.spi[attr={version=[1
.6.1.redhat-2]},dirs={}], org.slf4j.helpers[attr={version=[1.6.1.redhat-2]},dirs={}], ch.qos.cal10n[attr={version=[0.7.3-redhat-2]},dirs={}]], Bundle-
Version=1.6.1.redhat-2}
        at org.jboss.osgi.resolver.spi.AbstractResourceBuilder.loadFrom(AbstractResourceBuilder.java:281)
        at org.jboss.as.osgi.service.AutoInstallIntegration.installInitialModuleCapability(AutoInstallIntegration.java:216)
        at org.jboss.as.osgi.service.AutoInstallIntegration.start(AutoInstallIntegration.java:152)
        ... 5 more
Caused by: java.lang.NumberFormatException: For input string: "3-redhat-2"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_09]
        at java.lang.Integer.parseInt(Integer.java:492) [rt.jar:1.7.0_09]
        at java.lang.Integer.parseInt(Integer.java:527) [rt.jar:1.7.0_09]
        at org.osgi.framework.Version.<init>(Version.java:133)
        at org.jboss.osgi.metadata.VersionRange.parse(VersionRange.java:77)
        at org.jboss.osgi.resolver.spi.AbstractPackageRequirement.<init>(AbstractPackageRequirement.java:57)
        at org.jboss.osgi.resolver.spi.AbstractResourceBuilder.addPackageRequirement(AbstractResourceBuilder.java:147)
        at org.jboss.osgi.resolver.spi.AbstractResourceBuilder.loadFrom(AbstractResourceBuilder.java:265)
        ... 7 more
--


Expected results:
No exceptions.


Additional info:
In the MANIFEST.MF of the jar file of 'org.slf4j.ext' module:
--
Import-Package: org.slf4j;version=1.6.1.redhat-2, org.slf4j.spi;versio
 n=1.6.1.redhat-2, org.slf4j.helpers;version=1.6.1.redhat-2, ch.qos.ca
 l10n;version=0.7.3-redhat-2
--

In the MANIFEST.MF of the jar file of 'ch.qos.cal10n' module:
--
Export-Package: ch.qos.cal10n;version=0.7.3-redhat-2, ch.qos.cal10n.ut
 il;version=0.7.3-redhat-2
--

Note the version string of 'ch.qos.cal10n' is '0.7.3-redhat-2' in both cases.  That version delimiter between the micro and the qualifier should be a period, '0.7.3.redhat-2'.  You can find the grammar in the JavaDoc [1].

[1] http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#Version%28java.lang.String%29

Comment 2 Odin Trisk 2013-08-19 09:57:35 UTC
Related ??? 

https://bugzilla.redhat.com/show_bug.cgi?id=900247

Comment 3 Odin Trisk 2013-08-19 09:59:34 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

Comment 4 Odin Trisk 2013-08-19 10:13:42 UTC
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.

Comment 5 Thomas Diesler 2013-08-19 10:17:21 UTC
Can we not just remove the OSGi subsystem/tests? It has been removed in wildlfy already.

Comment 6 Odin Trisk 2013-08-19 18:19:55 UTC
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.

Comment 7 Thomas Diesler 2013-08-20 07:58:59 UTC
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.

Comment 10 Brad Maxwell 2015-11-24 23:23:05 UTC
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