[jira] Commented: (FELIX-650) Bundle-SymbolicName not handled correctly when header contains parameters

["Richard S. Hall (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617805#action_12617805 ] 

Richard S. Hall commented on FELIX-650:
---------------------------------------

I will look into this patch when I look into your other patch, later this week. Thanks for the feedback.

> 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.