felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sahoo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-682) Package.getImplementationVersion returns null for package loaded by Felix
Date Fri, 15 Aug 2008 20:21:44 GMT

    [ https://issues.apache.org/jira/browse/FELIX-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623005#action_12623005

Sahoo commented on FELIX-682:


Why do you say what I specify is non-compliant? Are you getting confused by presence of "=".
That was the output of headers command of Felix shell. Download the test case and look at
the manifest file that gets generated by "mvn install."

Look at http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html. A jar can't
have multiple Implementation-Version attribute in its manifest header. One can definitely
write a custom class loader that looks for the information in some other place instead of
relying on manifest entries for these entries, but that seems so unrealistic because the same
jar when used in non-OSGi environment would yield different result.


Yes, we have some non-OSGi clients that use Package API. 

Marcel, Richard,

Yes, I understand Package API has limitations and OSGi has better facilities, but if we stick
to the original use case of Java extensions (http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html),
then they are still useful. The original intention was something like this:

A particular technology defines a namespace. The namespace is identified by the primary package
name of the APIs defined by that technology. e.g., JAXB specification defines javax.xml.bind
namespace. The JAXB implementation jar supplied by Sun Microsystems can then have following
manifest entries:

Extension-Name: javax.xml.bind
Specification-Title: Java API for XML Binding
Specification-Version: 2.1
Specification-Vendor: Sun Microsystems, Inc.
Implementation-Version: foobar
Implementation-Vendor-Id: com.sun

Such a bundle should also include JAXB API classes. Only then, when user asks javax.xml.bind.SomeClass.class.getPackage().getImplementationVersion(),
will they get foobar.

> Package.getImplementationVersion returns null for package loaded by Felix
> -------------------------------------------------------------------------
>                 Key: FELIX-682
>                 URL: https://issues.apache.org/jira/browse/FELIX-682
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: felix-1.0.4
>         Environment: NA
>            Reporter: Sahoo
>             Fix For: felix-1.2.0
>         Attachments: Felix-682.zip
> Even though MANIFEST.MF has proper entry for Implementation-Version, Package.getImplementationVersion()
returns null. A  reproducible test case is attached. It is described below:
> public class Foo implements BundleActivator {
>     public void start(BundleContext context) throws Exception {
>         Package p = getClass().getPackage();
>         System.out.println(p);
>         System.out.println(p.getImplementationVersion());
>    }
> }
> The headers for this bundle are:
> osgi-test1 (10)
> ---------------
> Tool = Bnd-0.0.255
> Bundle-Activator = sahoo.osgitest1.Foo
> Implementation-Version = 1.0-SNAPSHOT
> Implementation-Vendor-Id = sahoo
> Bundle-Version = 1.0.0.SNAPSHOT
> Build-Jdk = 1.5.0_13-rev
> Implementation-Title = osgi-test1
> Created-By = Apache Maven Bundle Plugin
> Bundle-ManifestVersion = 2
> Manifest-Version = 1.0
> Bnd-LastModified = 1218821794953
> Private-Package = sahoo.osgitest1
> Bundle-Name = osgi-test1
> Built-By = ss141213
> Import-Package = org.osgi.framework;version="1.3"
> Bundle-SymbolicName = sahoo.osgi-test1

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message