You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Alin Dreghiciu (JIRA)" <ji...@apache.org> on 2008/07/29 14:12:31 UTC

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

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


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.


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

Posted by "Alin Dreghiciu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alin Dreghiciu closed FELIX-650.
--------------------------------


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


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

Posted by "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=12619054#action_12619054 ] 

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

Yes, Felix still has to be compatible with R3 bundles.

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


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

Posted by "Alin Dreghiciu (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alin Dreghiciu updated FELIX-650:
---------------------------------

    Attachment: FELIX-650.patch

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


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

Posted by "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.


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

Posted by "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=12617821#action_12617821 ] 

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

Agreed, the current behavior is incorrect, I just didn't want you disappointed. :-)

If you create your singleton jira patch before this one is applied, then just include them together and close this bug.

I agree that commit rights would make this simpler and supplying patches is the primary way to gain commit rights, so you are on the right path regardless what happens with Pax Web. :-)

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


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

Posted by "Alin Dreghiciu (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617817#action_12617817 ] 

Alin Dreghiciu commented on FELIX-650:
--------------------------------------

I know that Felix does not implement the singleton support. But that is another story that I'm working on. I will create an issue/pacth for that also as I'm pretty close to have it done.
But even without the support the current behavior is incorrect in case that the Bundle-SymbolicnNme is not just a simple string without attributes/directives.

BTW, I do not know what to do now regrading the singleton support. Shall I base the patch on the patch from this issu or on the current code base? Right now I'm working against the current code base.

It would had been more simpler if I would have commit rights :). But maybe in the future when Pax Web will become a Felix project.

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


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

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall updated FELIX-650:
----------------------------------

    Fix Version/s: felix-1.2.0

> 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
>             Fix For: felix-1.2.0
>
>         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.


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

Posted by "Alin Dreghiciu (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619052#action_12619052 ] 

Alin Dreghiciu commented on FELIX-650:
--------------------------------------

Interesting. Bundle-SymbolicName is a mandatory header. Are we talking about R3?


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


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

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/FELIX-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard S. Hall reassigned FELIX-650:
-------------------------------------

    Assignee: Richard S. Hall

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


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

Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
     [ 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.


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

Posted by "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 ] 

rickhall edited comment on FELIX-650 at 7/29/08 7:51 AM:
----------------------------------------------------------------

I will look into this patch when I look into your other patch, later this week. Thanks for the feedback. Keep in mind that Felix does not currently implement singleton support.

      was (Author: rickhall):
    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.