[
https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-650.
-----------------------------------
Resolution: Fixed
I have applied this patch. There was a small bug in that it assume that all
bundles have symbolic names, but since that is not the case, I had to add a
check for null.
Alin, please close this bug if you are satisfied. Thanks.
> Bundle-SymbolicName not handled correctly when header contains parameters
> -------------------------------------------------------------------------
>
> Key: FELIX-650
> URL: https://issues.apache.org/jira/browse/FELIX-650
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Reporter: Alin Dreghiciu
> Assignee: Richard S. Hall
> Attachments: FELIX-650.patch
>
>
> The OSGi specs mandates that syntax for Bundle-Symbolicname is:
> Bundle-SymbolicName ::= symbolic-name ( ';' parameter ) *
> meaning that you can add parameters to symbolic name as for example
> singleton:=true.
> Let's use the following as an example:
> Bundle-SymbolicName: org.ops4j.pax.url.mvn; singleton:=true
> If I use such an parameter the bundle symbolic name returned by Felix
> Bundle.getSymbolicName will be inclusive the parameters which is not correct.
> In the example above the returned value will be org.ops4j.pax.url.mvn;
> singleton:=true.
> The problem is that some places in Felix lookup the symbolic name using a
> pattern like:
> ((FelixBundle)
> bundle).getInfo().getCurrentHeader().get(Constants.BUNDLE_SYMBOLICNAME)
> so, searching the headers for symbolic name not the parsed value.
> This had the side effect of being able to install two bundles with same
> symbolic name and version, fact that is prohibited by the specs. Felix has
> the code to verify that you cannot install but the problem is that when
> installing a bundle the symbolic name comparation is doen between the parsed
> symbolic name of the bundle to be installed and the symbolic name of the
> other bundles (already installed) where the symbolic name is determined using
> the pattern above.
> You can see this behavior in the example bellow.
> I wil atach a path that solves this problem by changing the getSymbolicName
> to lookup the symbolic name in the parsed values ("module" ICapability of the
> current IModule) and change all the places that did it's own lookup of the
> symbolic name to use Bundle.getSymbolicName.
> But this is if we do not want an "invasive" change and it may not perform
> well as the lookup is done all the time. A better cleaner/solution would be
> to add symbolic name (and maybe version) to IModuleDefinition (I would say
> but I'm not very aware of Felix implementation internals) and set the values
> while creating the module as the values are already parsed by ManifestParser
> (same place as when the capabilities/requirements are parsed/created).
> -> install
> file:/Users/alindreghiciu/.m2/repository/org/ops4j/pax/url/pax-url-mvn/0.3.0/pax-url-mvn-0.3.0.jar
> Bundle ID: 5
> -> ps -s
> START LEVEL 1
> ID State Level Symbolic name
> [ 0] [Active ] [ 0] System Bundle (1.0.4)
> [ 1] [Active ] [ 1] org.apache.felix.shell (1.0.1)
> [ 2] [Active ] [ 1] org.apache.felix.shell.tui (1.0.1)
> [ 3] [Active ] [ 1] org.apache.felix.bundlerepository (1.0.3)
> [ 5] [Installed ] [ 1] org.ops4j.pax.url.mvn; singleton:=true (0.3.0)
> -> install file:/Users/alindreghiciu/work/pax-url-mvn-0.3.0.jar
> Bundle ID: 7
> -> ps -s
> START LEVEL 1
> ID State Level Symbolic name
> [ 0] [Active ] [ 0] System Bundle (1.0.4)
> [ 1] [Active ] [ 1] org.apache.felix.shell (1.0.1)
> [ 2] [Active ] [ 1] org.apache.felix.shell.tui (1.0.1)
> [ 3] [Active ] [ 1] org.apache.felix.bundlerepository (1.0.3)
> [ 5] [Installed ] [ 1] org.ops4j.pax.url.mvn; singleton:=true (0.3.0)
> [ 7] [Installed ] [ 1] org.ops4j.pax.url.mvn; singleton:=true (0.3.0)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
