You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Matias SM <ma...@yahoo.com.ar> on 2012/04/01 18:32:27 UTC
OBR and automatic bundle update
Hi everybody,
I'm using OBR to help me resolve bundle deployment. Everything works
great and as expected but I'm facing a situation I don't know how to solve.
---------------------------------------
Here is my test scenario:
I have the following bundles in an OBR repository:
* SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: "p.a"
version: 1)
* SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
version: 1)
* SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
version: [1 , 2) )
* SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
Then my test runs as follows:
g! deploy -s DA
==> this also deploys A version 1.0.0.2 (I guess because it is the
"newer" bundle that exports "pa" version 1)
g! deploy -s A@1.0.0.1
==> this __updates__ the previously deployed A (version 1.0.0.2)
First "issue", if I run:
g!deploy -s A@1.0.0.2
==> then OBR executes successfully but A@1.0.0.2 is not installed
(since there is an "updated" version of it already resolved). I know
this is the expected behavior, but I would like to be able to deploy
A@1.0.0.2
Second (and worse) issue, if I now run:
g!refresh
==> so A@1.0.0.2 is completely uninstalled from the framework
And then:
g!deploy -s DexA
==> this deployment __fails__ because A@1.0.0.2 can't be
reinstalled in the framework!!
---------------------------------------
In the OBR project web page [1] can be read:
"OBR's deployment algorithm appears simple at first glance, but it is
actually somewhat complex due to the nature of deploying independently
developed bundles. For example, in an ideal world, if an update for a
bundle is made available, then updates for all of the bundles satisfying
its dependencies are also made available. Unfortunately, this may not be
the case, thus the deployment algorithm might have to install new
bundles during an update to satisfy either new dependencies or updated
dependencies that can no longer be satisfied by existing local bundles.
In response to this type of scenario, ___the OBR deployment algorithm
tries to favor updating existing bundles, if possible, as opposed to
installing new bundles to satisfy dependencies.____"
I don't fully understand this explanation but I get that the described
behavior is as intended.
My questions are:
1- Is there a way to force the installation of different bundle versions
(instead of the update of "older" ones) when deploying through OBR?
2- What kind of issues may this behavior (installation of different
versions) rise? (this is not considering the "problem" of having a lot
of bundles installed)
Note that while I'm using the shell to run my tests, my intention is to
use the OBR API in my code. So the "solution" may be available only in
the API.
Sorry the mail got so long but I wanted to state my problem as clear as
possible.
Thank you for taking the time to read and to answer!
Kind regards
[1]
http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
I will, thank you
On 05/04/12 16:12, Richard S. Hall wrote:
> Ok, great...watch the issue for any updates...
>
> -> richard
>
> On 4/5/12 15:01 , Matias SM wrote:
>> I just created it:
>>
>> Key: FELIX-3446
>> URL:https://issues.apache.org/jira/browse/FELIX-3446
>>
>> HTH, Kind Regards
>>
>>
>> On 05/04/12 15:15, Richard S. Hall wrote:
>>> Yes, please open a JIRA issue with the example bundles and a
>>> repository.xml file that I can play with.
>>>
>>> Thanks.
>>>
>>> -> richard
>>>
>>> On 4/5/12 12:53 , Matias SM wrote:
>>>> Hi Richard,
>>>> I've given this issue some more thought and I realized that my
>>>> starting point stands (a copy of the original mail is at the end of
>>>> this one).
>>>> If I try to execute these steps:
>>>>
>>>> g! deploy -s DA
>>>> g! deploy -s A@1.0.0.1
>>>> g! refresh
>>>> g! deploy -s DexA
>>>>
>>>> The deployment of DexA fails. If I understood correctly our
>>>> discussion about bundle's location string (first mail quote after
>>>> this one)and OBR , it shouldn't fail since OBR should try to deploy
>>>> A@1.0.0.2 as an update of A@1.0.0.1 (or, at least, to install it
>>>> using a different location string).
>>>>
>>>> The execution of the presented test case throws the following
>>>> exception (note I changed the output's bundle names and versions to
>>>> accommodate to the examples ones):
>>>> ////////////////////////////////////////////////////////////////////
>>>> Target resource(s):
>>>> -------------------
>>>> DexA (1.0.0)
>>>>
>>>> Deploying...
>>>> ERROR: Resolver: Start error - DexA
>>>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>>>> DexA [413]: Unable to resolve 413.0: missing requirement [413.0]
>>>> osgi.wiring.bundle;
>>>> (&(osgi.wiring.bundle=A)(bundle-version>=1.0.0.2)(bundle-version<=1.0.0.2))
>>>> at
>>>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>>>>
>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>>> at
>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
>>>> at
>>>> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
>>>> at org.apache.felix.gogo.command.OBR.deploy(OBR.java:387)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:616)
>>>> at
>>>> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>>>> at
>>>> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
>>>>
>>>> at
>>>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>>>> at
>>>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>>>>
>>>> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>>>> at
>>>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>>>> at org.apache.felix.gogo.shell.Console.run(Console.java:62)
>>>> at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
>>>> at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>> at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:616)
>>>> at
>>>> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>>>> at
>>>> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
>>>>
>>>> at
>>>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>>>> at
>>>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>>>>
>>>> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>>>> at
>>>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>>>> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
>>>> at java.lang.Thread.run(Thread.java:636)
>>>> done.
>>>> ////////////////////////////////////////////////////////////////////
>>>> After which bundle DexA is left installed (not resolved nor active)
>>>> in the framework:
>>>> g! lb
>>>> [... framework's bundles..]
>>>> 411|Active | 1|DA (1.0.0)
>>>> 412|Active | 1|A (1.0.0.1)
>>>> 413|Installed | 1|DexA (1.0.0)
>>>>
>>>> Am I missing something? Do you prefer I create a JIRA issue with
>>>> the bundles attached so you can do furtheranalysis?
>>>>
>>>> Kind regards and thank you!
>>>>
>>>> On 02/04/12 19:25, Richard S. Hall wrote:
>>>>> Yes, you are using the same path when you try to install the first
>>>>> bundle the second time and this will not work since that path is
>>>>> used as a unique key, which is why it returns the same bundle id
>>>>> as printed in your session since it did not install anything the
>>>>> second time.
>>>>>
>>>>> As I suggest you need to have two different paths.
>>>>>
>>>>> However, this isn't an issue for OBR since it uses an arbitrary
>>>>> location string, so it is always unique when it does an install,
>>>>> which you can't easily do from the shell, like I said before.
>>>>>
>>>>>
>>>>> Matias SM<ma...@yahoo.com.ar> wrote:
>>>> [....deleted some mails for ease of reading ...]
>>>>
>>>> On 02/04/12 14:40, Richard S. Hall wrote:
>>>>
>>>>> On 4/1/12 12:32, Matias SM wrote:
>>>>>> Hi everybody,
>>>>>> I'm using OBR to help me resolve bundle deployment. Everything works
>>>>>> great and as expected but I'm facing a situation I don't know how to
>>>>>> solve.
>>>>>> ---------------------------------------
>>>>>> Here is my test scenario:
>>>>>> I have the following bundles in an OBR repository:
>>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>>>>> "p.a" version: 1)
>>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
>>>>>> "p.a"
>>>>>> version: 1)
>>>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>>>>> version: [1 , 2) )
>>>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>>>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>>>>> Then my test runs as follows:
>>>>>> g! deploy -s DA
>>>>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>>>>> the "newer" bundle that exports "pa" version 1)
>>>>>> g! deploy -sA@1.0.0.1
>>>>>> ==> this __updates__ the previously deployed A (version
>>>>>> 1.0.0.2)
>>>>>> First "issue", if I run:
>>>>>> g!deploy -sA@1.0.0.2
>>>>>> ==> then OBR executes successfully butA@1.0.0.2 is not
>>>>>> installed
>>>>>> (since there is an "updated" version of it already resolved). I know
>>>>>> this is the expected behavior, but I would like to be able to deploy
>>>>>> A@1.0.0.2
>>>>> It seems like OBR should probably be performing a refresh after it
>>>>> does an update, so there isn't an older version hanging around.
>>>>>> Second (and worse) issue, if I now run:
>>>>>> g!refresh
>>>>>> ==> soA@1.0.0.2 is completely uninstalled from the framework
>>>>>> And then:
>>>>>> g!deploy -s DexA
>>>>>> ==> this deployment __fails__ becauseA@1.0.0.2 can't be
>>>>>> reinstalled in the framework!!
>>>>> Not sure why that would be. Are you seeing some sort of error?
>>>>>> ---------------------------------------
>>>>>> In the OBR project web page [1] can be read:
>>>>>> "OBR's deployment algorithm appears simple at first glance, but
>>>>>> it is
>>>>>> actually somewhat complex due to the nature of deploying
>>>>>> independently developed bundles. For example, in an ideal world, if
>>>>>> an update for a bundle is made available, then updates for all of
>>>>>> the
>>>>>> bundles satisfying its dependencies are also made available.
>>>>>> Unfortunately, this may not be the case, thus the deployment
>>>>>> algorithm might have to install new bundles during an update to
>>>>>> satisfy either new dependencies or updated dependencies that can no
>>>>>> longer be satisfied by existing local bundles. In response to this
>>>>>> type of scenario, ___the OBR deployment algorithm tries to favor
>>>>>> updating existing bundles, if possible, as opposed to installing new
>>>>>> bundles to satisfy dependencies.____"
>>>>>> I don't fully understand this explanation but I get that the
>>>>>> described behavior is as intended.
>>>>> Not sure which part you don't understand.
>>>>>> My questions are:
>>>>>> 1- Is there a way to force the installation of different bundle
>>>>>> versions (instead of the update of "older" ones) when deploying
>>>>>> through OBR?
>>>>> No, I don't think so.
>>>>>> 2- What kind of issues may this behavior (installation of different
>>>>>> versions) rise? (this is not considering the "problem" of having a
>>>>>> lot of bundles installed)
>>>>> Lots of providers is generally a bad thing since it creates many
>>>>> partitions in the overall class spaces of the bundles, meaning that
>>>>> collaboration among them becomes limited to little islands of bundles
>>>>> that happen to be using the same same providers.
>>>>>> Note that while I'm using the shell to run my tests, my intention is
>>>>>> to use the OBR API in my code. So the "solution" may be available
>>>>>> only in the API.
>>>>>> Sorry the mail got so long but I wanted to state my problem as clear
>>>>>> as possible.
>>>>>> Thank you for taking the time to read and to answer!
>>>>> Still not clear to me what the actual issue is or the solution,
>>>>> but at
>>>>> a minimum OBR should probably refresh after update.
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Ok, great...watch the issue for any updates...
-> richard
On 4/5/12 15:01 , Matias SM wrote:
> I just created it:
>
> Key: FELIX-3446
> URL:https://issues.apache.org/jira/browse/FELIX-3446
>
> HTH, Kind Regards
>
>
> On 05/04/12 15:15, Richard S. Hall wrote:
>> Yes, please open a JIRA issue with the example bundles and a
>> repository.xml file that I can play with.
>>
>> Thanks.
>>
>> -> richard
>>
>> On 4/5/12 12:53 , Matias SM wrote:
>>> Hi Richard,
>>> I've given this issue some more thought and I realized that my
>>> starting point stands (a copy of the original mail is at the end of
>>> this one).
>>> If I try to execute these steps:
>>>
>>> g! deploy -s DA
>>> g! deploy -s A@1.0.0.1
>>> g! refresh
>>> g! deploy -s DexA
>>>
>>> The deployment of DexA fails. If I understood correctly our
>>> discussion about bundle's location string (first mail quote after
>>> this one)and OBR , it shouldn't fail since OBR should try to deploy
>>> A@1.0.0.2 as an update of A@1.0.0.1 (or, at least, to install it
>>> using a different location string).
>>>
>>> The execution of the presented test case throws the following
>>> exception (note I changed the output's bundle names and versions to
>>> accommodate to the examples ones):
>>> ////////////////////////////////////////////////////////////////////
>>> Target resource(s):
>>> -------------------
>>> DexA (1.0.0)
>>>
>>> Deploying...
>>> ERROR: Resolver: Start error - DexA
>>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>>> DexA [413]: Unable to resolve 413.0: missing requirement [413.0]
>>> osgi.wiring.bundle;
>>> (&(osgi.wiring.bundle=A)(bundle-version>=1.0.0.2)(bundle-version<=1.0.0.2))
>>> at
>>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
>>> at
>>> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
>>> at org.apache.felix.gogo.command.OBR.deploy(OBR.java:387)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:616)
>>> at
>>> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>>> at
>>> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
>>>
>>> at
>>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>>> at
>>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>>>
>>> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>>> at
>>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>>> at org.apache.felix.gogo.shell.Console.run(Console.java:62)
>>> at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
>>> at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:616)
>>> at
>>> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>>> at
>>> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
>>>
>>> at
>>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>>> at
>>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>>>
>>> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>>> at
>>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>>> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
>>> at java.lang.Thread.run(Thread.java:636)
>>> done.
>>> ////////////////////////////////////////////////////////////////////
>>> After which bundle DexA is left installed (not resolved nor active)
>>> in the framework:
>>> g! lb
>>> [... framework's bundles..]
>>> 411|Active | 1|DA (1.0.0)
>>> 412|Active | 1|A (1.0.0.1)
>>> 413|Installed | 1|DexA (1.0.0)
>>>
>>> Am I missing something? Do you prefer I create a JIRA issue with the
>>> bundles attached so you can do furtheranalysis?
>>>
>>> Kind regards and thank you!
>>>
>>> On 02/04/12 19:25, Richard S. Hall wrote:
>>>> Yes, you are using the same path when you try to install the first
>>>> bundle the second time and this will not work since that path is
>>>> used as a unique key, which is why it returns the same bundle id as
>>>> printed in your session since it did not install anything the
>>>> second time.
>>>>
>>>> As I suggest you need to have two different paths.
>>>>
>>>> However, this isn't an issue for OBR since it uses an arbitrary
>>>> location string, so it is always unique when it does an install,
>>>> which you can't easily do from the shell, like I said before.
>>>>
>>>>
>>>> Matias SM<ma...@yahoo.com.ar> wrote:
>>> [....deleted some mails for ease of reading ...]
>>>
>>> On 02/04/12 14:40, Richard S. Hall wrote:
>>>
>>>> On 4/1/12 12:32, Matias SM wrote:
>>>>> Hi everybody,
>>>>> I'm using OBR to help me resolve bundle deployment. Everything works
>>>>> great and as expected but I'm facing a situation I don't know how to
>>>>> solve.
>>>>> ---------------------------------------
>>>>> Here is my test scenario:
>>>>> I have the following bundles in an OBR repository:
>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>>>> "p.a" version: 1)
>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
>>>>> version: 1)
>>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>>>> version: [1 , 2) )
>>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>>>> Then my test runs as follows:
>>>>> g! deploy -s DA
>>>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>>>> the "newer" bundle that exports "pa" version 1)
>>>>> g! deploy -sA@1.0.0.1
>>>>> ==> this __updates__ the previously deployed A (version
>>>>> 1.0.0.2)
>>>>> First "issue", if I run:
>>>>> g!deploy -sA@1.0.0.2
>>>>> ==> then OBR executes successfully butA@1.0.0.2 is not
>>>>> installed
>>>>> (since there is an "updated" version of it already resolved). I know
>>>>> this is the expected behavior, but I would like to be able to deploy
>>>>> A@1.0.0.2
>>>> It seems like OBR should probably be performing a refresh after it
>>>> does an update, so there isn't an older version hanging around.
>>>>> Second (and worse) issue, if I now run:
>>>>> g!refresh
>>>>> ==> soA@1.0.0.2 is completely uninstalled from the framework
>>>>> And then:
>>>>> g!deploy -s DexA
>>>>> ==> this deployment __fails__ becauseA@1.0.0.2 can't be
>>>>> reinstalled in the framework!!
>>>> Not sure why that would be. Are you seeing some sort of error?
>>>>> ---------------------------------------
>>>>> In the OBR project web page [1] can be read:
>>>>> "OBR's deployment algorithm appears simple at first glance, but it is
>>>>> actually somewhat complex due to the nature of deploying
>>>>> independently developed bundles. For example, in an ideal world, if
>>>>> an update for a bundle is made available, then updates for all of the
>>>>> bundles satisfying its dependencies are also made available.
>>>>> Unfortunately, this may not be the case, thus the deployment
>>>>> algorithm might have to install new bundles during an update to
>>>>> satisfy either new dependencies or updated dependencies that can no
>>>>> longer be satisfied by existing local bundles. In response to this
>>>>> type of scenario, ___the OBR deployment algorithm tries to favor
>>>>> updating existing bundles, if possible, as opposed to installing new
>>>>> bundles to satisfy dependencies.____"
>>>>> I don't fully understand this explanation but I get that the
>>>>> described behavior is as intended.
>>>> Not sure which part you don't understand.
>>>>> My questions are:
>>>>> 1- Is there a way to force the installation of different bundle
>>>>> versions (instead of the update of "older" ones) when deploying
>>>>> through OBR?
>>>> No, I don't think so.
>>>>> 2- What kind of issues may this behavior (installation of different
>>>>> versions) rise? (this is not considering the "problem" of having a
>>>>> lot of bundles installed)
>>>> Lots of providers is generally a bad thing since it creates many
>>>> partitions in the overall class spaces of the bundles, meaning that
>>>> collaboration among them becomes limited to little islands of bundles
>>>> that happen to be using the same same providers.
>>>>> Note that while I'm using the shell to run my tests, my intention is
>>>>> to use the OBR API in my code. So the "solution" may be available
>>>>> only in the API.
>>>>> Sorry the mail got so long but I wanted to state my problem as clear
>>>>> as possible.
>>>>> Thank you for taking the time to read and to answer!
>>>> Still not clear to me what the actual issue is or the solution, but at
>>>> a minimum OBR should probably refresh after update.
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
I just created it:
Key: FELIX-3446
URL:https://issues.apache.org/jira/browse/FELIX-3446
HTH, Kind Regards
On 05/04/12 15:15, Richard S. Hall wrote:
> Yes, please open a JIRA issue with the example bundles and a
> repository.xml file that I can play with.
>
> Thanks.
>
> -> richard
>
> On 4/5/12 12:53 , Matias SM wrote:
>> Hi Richard,
>> I've given this issue some more thought and I realized that my
>> starting point stands (a copy of the original mail is at the end of
>> this one).
>> If I try to execute these steps:
>>
>> g! deploy -s DA
>> g! deploy -s A@1.0.0.1
>> g! refresh
>> g! deploy -s DexA
>>
>> The deployment of DexA fails. If I understood correctly our
>> discussion about bundle's location string (first mail quote after
>> this one)and OBR , it shouldn't fail since OBR should try to deploy
>> A@1.0.0.2 as an update of A@1.0.0.1 (or, at least, to install it
>> using a different location string).
>>
>> The execution of the presented test case throws the following
>> exception (note I changed the output's bundle names and versions to
>> accommodate to the examples ones):
>> ////////////////////////////////////////////////////////////////////
>> Target resource(s):
>> -------------------
>> DexA (1.0.0)
>>
>> Deploying...
>> ERROR: Resolver: Start error - DexA
>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>> DexA [413]: Unable to resolve 413.0: missing requirement [413.0]
>> osgi.wiring.bundle;
>> (&(osgi.wiring.bundle=A)(bundle-version>=1.0.0.2)(bundle-version<=1.0.0.2))
>> at
>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
>> at
>> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
>> at org.apache.felix.gogo.command.OBR.deploy(OBR.java:387)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:616)
>> at
>> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>> at
>> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
>> at
>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>> at
>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>> at
>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>> at org.apache.felix.gogo.shell.Console.run(Console.java:62)
>> at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
>> at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:616)
>> at
>> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
>> at
>> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
>> at
>> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
>> at
>> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
>> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
>> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
>> at
>> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
>> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
>> at java.lang.Thread.run(Thread.java:636)
>> done.
>> ////////////////////////////////////////////////////////////////////
>> After which bundle DexA is left installed (not resolved nor active)
>> in the framework:
>> g! lb
>> [... framework's bundles..]
>> 411|Active | 1|DA (1.0.0)
>> 412|Active | 1|A (1.0.0.1)
>> 413|Installed | 1|DexA (1.0.0)
>>
>> Am I missing something? Do you prefer I create a JIRA issue with the
>> bundles attached so you can do furtheranalysis?
>>
>> Kind regards and thank you!
>>
>> On 02/04/12 19:25, Richard S. Hall wrote:
>>> Yes, you are using the same path when you try to install the first
>>> bundle the second time and this will not work since that path is
>>> used as a unique key, which is why it returns the same bundle id as
>>> printed in your session since it did not install anything the second
>>> time.
>>>
>>> As I suggest you need to have two different paths.
>>>
>>> However, this isn't an issue for OBR since it uses an arbitrary
>>> location string, so it is always unique when it does an install,
>>> which you can't easily do from the shell, like I said before.
>>>
>>>
>>> Matias SM<ma...@yahoo.com.ar> wrote:
>> [....deleted some mails for ease of reading ...]
>>
>> On 02/04/12 14:40, Richard S. Hall wrote:
>>
>>> On 4/1/12 12:32, Matias SM wrote:
>>>> Hi everybody,
>>>> I'm using OBR to help me resolve bundle deployment. Everything works
>>>> great and as expected but I'm facing a situation I don't know how to
>>>> solve.
>>>> ---------------------------------------
>>>> Here is my test scenario:
>>>> I have the following bundles in an OBR repository:
>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>>> "p.a" version: 1)
>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
>>>> version: 1)
>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>>> version: [1 , 2) )
>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>>> Then my test runs as follows:
>>>> g! deploy -s DA
>>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>>> the "newer" bundle that exports "pa" version 1)
>>>> g! deploy -sA@1.0.0.1
>>>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>>> First "issue", if I run:
>>>> g!deploy -sA@1.0.0.2
>>>> ==> then OBR executes successfully butA@1.0.0.2 is not
>>>> installed
>>>> (since there is an "updated" version of it already resolved). I know
>>>> this is the expected behavior, but I would like to be able to deploy
>>>> A@1.0.0.2
>>> It seems like OBR should probably be performing a refresh after it
>>> does an update, so there isn't an older version hanging around.
>>>> Second (and worse) issue, if I now run:
>>>> g!refresh
>>>> ==> soA@1.0.0.2 is completely uninstalled from the framework
>>>> And then:
>>>> g!deploy -s DexA
>>>> ==> this deployment __fails__ becauseA@1.0.0.2 can't be
>>>> reinstalled in the framework!!
>>> Not sure why that would be. Are you seeing some sort of error?
>>>> ---------------------------------------
>>>> In the OBR project web page [1] can be read:
>>>> "OBR's deployment algorithm appears simple at first glance, but it is
>>>> actually somewhat complex due to the nature of deploying
>>>> independently developed bundles. For example, in an ideal world, if
>>>> an update for a bundle is made available, then updates for all of the
>>>> bundles satisfying its dependencies are also made available.
>>>> Unfortunately, this may not be the case, thus the deployment
>>>> algorithm might have to install new bundles during an update to
>>>> satisfy either new dependencies or updated dependencies that can no
>>>> longer be satisfied by existing local bundles. In response to this
>>>> type of scenario, ___the OBR deployment algorithm tries to favor
>>>> updating existing bundles, if possible, as opposed to installing new
>>>> bundles to satisfy dependencies.____"
>>>> I don't fully understand this explanation but I get that the
>>>> described behavior is as intended.
>>> Not sure which part you don't understand.
>>>> My questions are:
>>>> 1- Is there a way to force the installation of different bundle
>>>> versions (instead of the update of "older" ones) when deploying
>>>> through OBR?
>>> No, I don't think so.
>>>> 2- What kind of issues may this behavior (installation of different
>>>> versions) rise? (this is not considering the "problem" of having a
>>>> lot of bundles installed)
>>> Lots of providers is generally a bad thing since it creates many
>>> partitions in the overall class spaces of the bundles, meaning that
>>> collaboration among them becomes limited to little islands of bundles
>>> that happen to be using the same same providers.
>>>> Note that while I'm using the shell to run my tests, my intention is
>>>> to use the OBR API in my code. So the "solution" may be available
>>>> only in the API.
>>>> Sorry the mail got so long but I wanted to state my problem as clear
>>>> as possible.
>>>> Thank you for taking the time to read and to answer!
>>> Still not clear to me what the actual issue is or the solution, but at
>>> a minimum OBR should probably refresh after update.
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, please open a JIRA issue with the example bundles and a
repository.xml file that I can play with.
Thanks.
-> richard
On 4/5/12 12:53 , Matias SM wrote:
> Hi Richard,
> I've given this issue some more thought and I realized that my
> starting point stands (a copy of the original mail is at the end of
> this one).
> If I try to execute these steps:
>
> g! deploy -s DA
> g! deploy -s A@1.0.0.1
> g! refresh
> g! deploy -s DexA
>
> The deployment of DexA fails. If I understood correctly our discussion
> about bundle's location string (first mail quote after this one)and
> OBR , it shouldn't fail since OBR should try to deploy A@1.0.0.2 as an
> update of A@1.0.0.1 (or, at least, to install it using a different
> location string).
>
> The execution of the presented test case throws the following
> exception (note I changed the output's bundle names and versions to
> accommodate to the examples ones):
> ////////////////////////////////////////////////////////////////////
> Target resource(s):
> -------------------
> DexA (1.0.0)
>
> Deploying...
> ERROR: Resolver: Start error - DexA
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> DexA [413]: Unable to resolve 413.0: missing requirement [413.0]
> osgi.wiring.bundle;
> (&(osgi.wiring.bundle=A)(bundle-version>=1.0.0.2)(bundle-version<=1.0.0.2))
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at
> org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
> at org.apache.felix.gogo.command.OBR.deploy(OBR.java:387)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
> at
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
> at org.apache.felix.gogo.shell.Console.run(Console.java:62)
> at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
> at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
> at
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
> at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
> at
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
> at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
> at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
> at
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
> at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
> at java.lang.Thread.run(Thread.java:636)
> done.
> ////////////////////////////////////////////////////////////////////
> After which bundle DexA is left installed (not resolved nor active) in
> the framework:
> g! lb
> [... framework's bundles..]
> 411|Active | 1|DA (1.0.0)
> 412|Active | 1|A (1.0.0.1)
> 413|Installed | 1|DexA (1.0.0)
>
> Am I missing something? Do you prefer I create a JIRA issue with the
> bundles attached so you can do furtheranalysis?
>
> Kind regards and thank you!
>
> On 02/04/12 19:25, Richard S. Hall wrote:
>> Yes, you are using the same path when you try to install the first
>> bundle the second time and this will not work since that path is used
>> as a unique key, which is why it returns the same bundle id as
>> printed in your session since it did not install anything the second
>> time.
>>
>> As I suggest you need to have two different paths.
>>
>> However, this isn't an issue for OBR since it uses an arbitrary
>> location string, so it is always unique when it does an install,
>> which you can't easily do from the shell, like I said before.
>>
>>
>> Matias SM<ma...@yahoo.com.ar> wrote:
> [....deleted some mails for ease of reading ...]
>
> On 02/04/12 14:40, Richard S. Hall wrote:
>
>> On 4/1/12 12:32, Matias SM wrote:
>>> Hi everybody,
>>> I'm using OBR to help me resolve bundle deployment. Everything works
>>> great and as expected but I'm facing a situation I don't know how to
>>> solve.
>>> ---------------------------------------
>>> Here is my test scenario:
>>> I have the following bundles in an OBR repository:
>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>> "p.a" version: 1)
>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
>>> version: 1)
>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>> version: [1 , 2) )
>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>> Then my test runs as follows:
>>> g! deploy -s DA
>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>> the "newer" bundle that exports "pa" version 1)
>>> g! deploy -sA@1.0.0.1
>>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>> First "issue", if I run:
>>> g!deploy -sA@1.0.0.2
>>> ==> then OBR executes successfully butA@1.0.0.2 is not installed
>>> (since there is an "updated" version of it already resolved). I know
>>> this is the expected behavior, but I would like to be able to deploy
>>> A@1.0.0.2
>> It seems like OBR should probably be performing a refresh after it
>> does an update, so there isn't an older version hanging around.
>>> Second (and worse) issue, if I now run:
>>> g!refresh
>>> ==> soA@1.0.0.2 is completely uninstalled from the framework
>>> And then:
>>> g!deploy -s DexA
>>> ==> this deployment __fails__ becauseA@1.0.0.2 can't be
>>> reinstalled in the framework!!
>> Not sure why that would be. Are you seeing some sort of error?
>>> ---------------------------------------
>>> In the OBR project web page [1] can be read:
>>> "OBR's deployment algorithm appears simple at first glance, but it is
>>> actually somewhat complex due to the nature of deploying
>>> independently developed bundles. For example, in an ideal world, if
>>> an update for a bundle is made available, then updates for all of the
>>> bundles satisfying its dependencies are also made available.
>>> Unfortunately, this may not be the case, thus the deployment
>>> algorithm might have to install new bundles during an update to
>>> satisfy either new dependencies or updated dependencies that can no
>>> longer be satisfied by existing local bundles. In response to this
>>> type of scenario, ___the OBR deployment algorithm tries to favor
>>> updating existing bundles, if possible, as opposed to installing new
>>> bundles to satisfy dependencies.____"
>>> I don't fully understand this explanation but I get that the
>>> described behavior is as intended.
>> Not sure which part you don't understand.
>>> My questions are:
>>> 1- Is there a way to force the installation of different bundle
>>> versions (instead of the update of "older" ones) when deploying
>>> through OBR?
>> No, I don't think so.
>>> 2- What kind of issues may this behavior (installation of different
>>> versions) rise? (this is not considering the "problem" of having a
>>> lot of bundles installed)
>> Lots of providers is generally a bad thing since it creates many
>> partitions in the overall class spaces of the bundles, meaning that
>> collaboration among them becomes limited to little islands of bundles
>> that happen to be using the same same providers.
>>> Note that while I'm using the shell to run my tests, my intention is
>>> to use the OBR API in my code. So the "solution" may be available
>>> only in the API.
>>> Sorry the mail got so long but I wanted to state my problem as clear
>>> as possible.
>>> Thank you for taking the time to read and to answer!
>> Still not clear to me what the actual issue is or the solution, but at
>> a minimum OBR should probably refresh after update.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
Hi Richard,
I've given this issue some more thought and I realized that my starting
point stands (a copy of the original mail is at the end of this one).
If I try to execute these steps:
g! deploy -s DA
g! deploy -s A@1.0.0.1
g! refresh
g! deploy -s DexA
The deployment of DexA fails. If I understood correctly our discussion
about bundle's location string (first mail quote after this one)and OBR
, it shouldn't fail since OBR should try to deploy A@1.0.0.2 as an
update of A@1.0.0.1 (or, at least, to install it using a different
location string).
The execution of the presented test case throws the following exception
(note I changed the output's bundle names and versions to accommodate to
the examples ones):
////////////////////////////////////////////////////////////////////
Target resource(s):
-------------------
DexA (1.0.0)
Deploying...
ERROR: Resolver: Start error - DexA
org.osgi.framework.BundleException: Unresolved constraint in bundle DexA
[413]: Unable to resolve 413.0: missing requirement [413.0]
osgi.wiring.bundle;
(&(osgi.wiring.bundle=A)(bundle-version>=1.0.0.2)(bundle-version<=1.0.0.2))
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
at
org.apache.felix.bundlerepository.impl.ResolverImpl.deploy(ResolverImpl.java:630)
at org.apache.felix.gogo.command.OBR.deploy(OBR.java:387)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.gogo.shell.Console.run(Console.java:62)
at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:137)
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.gogo.shell.Activator.run(Activator.java:75)
at java.lang.Thread.run(Thread.java:636)
done.
////////////////////////////////////////////////////////////////////
After which bundle DexA is left installed (not resolved nor active) in
the framework:
g! lb
[... framework's bundles..]
411|Active | 1|DA (1.0.0)
412|Active | 1|A (1.0.0.1)
413|Installed | 1|DexA (1.0.0)
Am I missing something? Do you prefer I create a JIRA issue with the
bundles attached so you can do furtheranalysis?
Kind regards and thank you!
On 02/04/12 19:25, Richard S. Hall wrote:
> Yes, you are using the same path when you try to install the first bundle the second time and this will not work since that path is used as a unique key, which is why it returns the same bundle id as printed in your session since it did not install anything the second time.
>
> As I suggest you need to have two different paths.
>
> However, this isn't an issue for OBR since it uses an arbitrary location string, so it is always unique when it does an install, which you can't easily do from the shell, like I said before.
>
>
> Matias SM<ma...@yahoo.com.ar> wrote:
[....deleted some mails for ease of reading ...]
On 02/04/12 14:40, Richard S. Hall wrote:
> On 4/1/12 12:32, Matias SM wrote:
>> Hi everybody,
>> I'm using OBR to help me resolve bundle deployment. Everything works
>> great and as expected but I'm facing a situation I don't know how to
>> solve.
>> ---------------------------------------
>> Here is my test scenario:
>> I have the following bundles in an OBR repository:
>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>> "p.a" version: 1)
>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
>> version: 1)
>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>> version: [1 , 2) )
>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>> Then my test runs as follows:
>> g! deploy -s DA
>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>> the "newer" bundle that exports "pa" version 1)
>> g! deploy -sA@1.0.0.1
>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>> First "issue", if I run:
>> g!deploy -sA@1.0.0.2
>> ==> then OBR executes successfully butA@1.0.0.2 is not installed
>> (since there is an "updated" version of it already resolved). I know
>> this is the expected behavior, but I would like to be able to deploy
>> A@1.0.0.2
> It seems like OBR should probably be performing a refresh after it
> does an update, so there isn't an older version hanging around.
>> Second (and worse) issue, if I now run:
>> g!refresh
>> ==> soA@1.0.0.2 is completely uninstalled from the framework
>> And then:
>> g!deploy -s DexA
>> ==> this deployment __fails__ becauseA@1.0.0.2 can't be
>> reinstalled in the framework!!
> Not sure why that would be. Are you seeing some sort of error?
>> ---------------------------------------
>> In the OBR project web page [1] can be read:
>> "OBR's deployment algorithm appears simple at first glance, but it is
>> actually somewhat complex due to the nature of deploying
>> independently developed bundles. For example, in an ideal world, if
>> an update for a bundle is made available, then updates for all of the
>> bundles satisfying its dependencies are also made available.
>> Unfortunately, this may not be the case, thus the deployment
>> algorithm might have to install new bundles during an update to
>> satisfy either new dependencies or updated dependencies that can no
>> longer be satisfied by existing local bundles. In response to this
>> type of scenario, ___the OBR deployment algorithm tries to favor
>> updating existing bundles, if possible, as opposed to installing new
>> bundles to satisfy dependencies.____"
>> I don't fully understand this explanation but I get that the
>> described behavior is as intended.
> Not sure which part you don't understand.
>> My questions are:
>> 1- Is there a way to force the installation of different bundle
>> versions (instead of the update of "older" ones) when deploying
>> through OBR?
> No, I don't think so.
>> 2- What kind of issues may this behavior (installation of different
>> versions) rise? (this is not considering the "problem" of having a
>> lot of bundles installed)
> Lots of providers is generally a bad thing since it creates many
> partitions in the overall class spaces of the bundles, meaning that
> collaboration among them becomes limited to little islands of bundles
> that happen to be using the same same providers.
>> Note that while I'm using the shell to run my tests, my intention is
>> to use the OBR API in my code. So the "solution" may be available
>> only in the API.
>> Sorry the mail got so long but I wanted to state my problem as clear
>> as possible.
>> Thank you for taking the time to read and to answer!
> Still not clear to me what the actual issue is or the solution, but at
> a minimum OBR should probably refresh after update.
>
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
Ok, thank you very much for your comments Richard.
I will keep them in mind and do further experimentation.
On 02/04/12 21:25, Richard S. Hall wrote:
> The location string is a deployer assigned persistent identifier, so it cannot change. Your confusion arises because frameworks use the URL as the default location string for simple installs, but the two are unrelated in reality.
>
> Matias SM<ma...@yahoo.com.ar> wrote:
>
>> Ok, I see. Shouldn't the location string be replaced (with the updated
>> version location) when the bundle is updated? It seems a little
>> confusing.
>>
>> Thank you very much for the clarification, I will do some more
>> experimentation keeping in mind what we discussed.
>>
>> On 02/04/12 19:25, Richard S. Hall wrote:
>>> Yes, you are using the same path when you try to install the first
>> bundle the second time and this will not work since that path is used
>> as a unique key, which is why it returns the same bundle id as printed
>> in your session since it did not install anything the second time.
>>> As I suggest you need to have two different paths.
>>>
>>> However, this isn't an issue for OBR since it uses an arbitrary
>> location string, so it is always unique when it does an install, which
>> you can't easily do from the shell, like I said before.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
The location string is a deployer assigned persistent identifier, so it cannot change. Your confusion arises because frameworks use the URL as the default location string for simple installs, but the two are unrelated in reality.
Matias SM <ma...@yahoo.com.ar> wrote:
>Ok, I see. Shouldn't the location string be replaced (with the updated
>version location) when the bundle is updated? It seems a little
>confusing.
>
>Thank you very much for the clarification, I will do some more
>experimentation keeping in mind what we discussed.
>
>On 02/04/12 19:25, Richard S. Hall wrote:
>> Yes, you are using the same path when you try to install the first
>bundle the second time and this will not work since that path is used
>as a unique key, which is why it returns the same bundle id as printed
>in your session since it did not install anything the second time.
>>
>> As I suggest you need to have two different paths.
>>
>> However, this isn't an issue for OBR since it uses an arbitrary
>location string, so it is always unique when it does an install, which
>you can't easily do from the shell, like I said before.
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org
--
Sent from my phone, excuse my brevity.
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
Ok, I see. Shouldn't the location string be replaced (with the updated
version location) when the bundle is updated? It seems a little confusing.
Thank you very much for the clarification, I will do some more
experimentation keeping in mind what we discussed.
On 02/04/12 19:25, Richard S. Hall wrote:
> Yes, you are using the same path when you try to install the first bundle the second time and this will not work since that path is used as a unique key, which is why it returns the same bundle id as printed in your session since it did not install anything the second time.
>
> As I suggest you need to have two different paths.
>
> However, this isn't an issue for OBR since it uses an arbitrary location string, so it is always unique when it does an install, which you can't easily do from the shell, like I said before.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, you are using the same path when you try to install the first bundle the second time and this will not work since that path is used as a unique key, which is why it returns the same bundle id as printed in your session since it did not install anything the second time.
As I suggest you need to have two different paths.
However, this isn't an issue for OBR since it uses an arbitrary location string, so it is always unique when it does an install, which you can't easily do from the shell, like I said before.
Matias SM <ma...@yahoo.com.ar> wrote:
>
>
>On 02/04/12 18:32, Richard S. Hall wrote:
>> On 4/2/12 17:05, Matias SM wrote:
>>>
>>>
>>> On 02/04/12 17:31, Richard S. Hall wrote:
>>>> On 4/2/12 15:42, Matias SM wrote:
>>>>> Thank you for your answer Richard, please see my comments inline:
>>>>>
>>>>> On 02/04/12 14:40, Richard S. Hall wrote:
>>>>>> On 4/1/12 12:32, Matias SM wrote:
>>>>>>> Hi everybody,
>>>>>>> I'm using OBR to help me resolve bundle deployment. Everything
>>>>>>> works great and as expected but I'm facing a situation I don't
>>>>>>> know how to solve.
>>>>>>>
>>>>>>> ---------------------------------------
>>>>>>> Here is my test scenario:
>>>>>>> I have the following bundles in an OBR repository:
>>>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>
>>>>>>> "p.a" version: 1)
>>>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
>>>>>>> "p.a" version: 1)
>>>>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>
>>>>>>> version: [1 , 2) )
>>>>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package:
>>>>>>> "p.a" version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2,
>>>>>>> 1.0.0.2] )
>>>>>>>
>>>>>>> Then my test runs as follows:
>>>>>>> g! deploy -s DA
>>>>>>> ==> this also deploys A version 1.0.0.2 (I guess because it
>>>>>>> is the "newer" bundle that exports "pa" version 1)
>>>>>>>
>>>>>>> g! deploy -s A@1.0.0.1
>>>>>>> ==> this __updates__ the previously deployed A (version
>1.0.0.2)
>>>>>>>
>>>>>>> First "issue", if I run:
>>>>>>> g!deploy -s A@1.0.0.2
>>>>>>> ==> then OBR executes successfully but A@1.0.0.2 is not
>>>>>>> installed (since there is an "updated" version of it already
>>>>>>> resolved). I know this is the expected behavior, but I would
>like
>>>>>>> to be able to deploy A@1.0.0.2
>>>>>>
>>>>>> It seems like OBR should probably be performing a refresh after
>it
>>>>>> does an update, so there isn't an older version hanging around.
>>>>>>
>>>>>>>
>>>>>>> Second (and worse) issue, if I now run:
>>>>>>> g!refresh
>>>>>>> ==> so A@1.0.0.2 is completely uninstalled from the
>framework
>>>>>>> And then:
>>>>>>> g!deploy -s DexA
>>>>>>> ==> this deployment __fails__ because A@1.0.0.2 can't be
>>>>>>> reinstalled in the framework!!
>>>>>>
>>>>>> Not sure why that would be. Are you seeing some sort of error?
>>>>>>
>>>>>
>>>>> I think that the "problem" here is that to be able to update the
>>>>> dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that
>
>>>>> was deployed in step 2). I don't think this should be a valid
>thing
>>>>> to do.
>>>>
>>>> Still seems like it should be possible for OBR to deploy DexA by
>>>> updating 1.0.0.1 to 1.0.0.2.
>>>
>>> Wouldn't that break the request that bundle A@1.0.0.1 is deployed
>>> (step 2 in test)?
>>
>> No. OBR doesn't keep some set of "desired deployed bundles" or
>> anything like that...it isn't that sophisticated. It simply tries to
>> deploy bundles given the current context of the framework. So, the
>> fact that you told OBR to deploy foo in some previous request has no
>> bearing on subsequent requests other than the fact that it impacts
>the
>> set of installed bundles from which it starts to perform its
>> operation...but that is no different than if you installed a given
>> bundle manually and didn't use OBR at all.
>>
>Ok, now I understand your point. Though I can see that this behavior
>may
>lead to some issues if bundle A@1.0.0.1 has some kind of functionality
>other than defining classes to export.
>
>>>
>>>>
>>>>>
>>>>>>> ---------------------------------------
>>>>>>>
>>>>>>> In the OBR project web page [1] can be read:
>>>>>>> "OBR's deployment algorithm appears simple at first glance, but
>>>>>>> it is actually somewhat complex due to the nature of deploying
>>>>>>> independently developed bundles. For example, in an ideal world,
>
>>>>>>> if an update for a bundle is made available, then updates for
>all
>>>>>>> of the bundles satisfying its dependencies are also made
>>>>>>> available. Unfortunately, this may not be the case, thus the
>>>>>>> deployment algorithm might have to install new bundles during an
>
>>>>>>> update to satisfy either new dependencies or updated
>dependencies
>>>>>>> that can no longer be satisfied by existing local bundles. In
>>>>>>> response to this type of scenario, ___the OBR deployment
>>>>>>> algorithm tries to favor updating existing bundles, if possible,
>
>>>>>>> as opposed to installing new bundles to satisfy
>dependencies.____"
>>>>>>>
>>>>>>> I don't fully understand this explanation but I get that the
>>>>>>> described behavior is as intended.
>>>>>>
>>>>>> Not sure which part you don't understand.
>>>>>
>>>>> What I don't understand is how the need to favor updating existing
>
>>>>> bundles is concluded from the problem stated in the previous
>>>>> sentences. It is not clear to me the relation between the need to
>>>>> "install new bundles during an update" and the algorithm that
>>>>> "tries to favor updating existing bundles instead of installing
>new
>>>>> ones".
>>>>
>>>> Ok, I see your point now. No, the one doesn't necessarily follow
>the
>>>> other. The reason to favor updating existing bundles is the reason
>I
>>>> gave below.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> My questions are:
>>>>>>> 1- Is there a way to force the installation of different bundle
>>>>>>> versions (instead of the update of "older" ones) when deploying
>>>>>>> through OBR?
>>>>>>
>>>>>> No, I don't think so.
>>>>>>
>>>>>>> 2- What kind of issues may this behavior (installation of
>>>>>>> different versions) rise? (this is not considering the "problem"
>
>>>>>>> of having a lot of bundles installed)
>>>>>>
>>>>>> Lots of providers is generally a bad thing since it creates many
>>>>>> partitions in the overall class spaces of the bundles, meaning
>>>>>> that collaboration among them becomes limited to little islands
>of
>>>>>> bundles that happen to be using the same same providers.
>>>>>>
>>>>> I understand. But updating the bundles may lead to the problem I
>>>>> presented, where a bundle can't be resolved despite all necessary
>>>>> resources are available.
>>>>>
>>>>> I know that this behavior is not defined by OBR but OSGi in
>>>>> general. But I don't understand why once a bundle is updated, an
>>>>> older version of it can't be re-installed so a bundle depending on
>
>>>>> it can be successfully resolved. I think that allowing this may
>>>>> help to avoid problems like the one presented (note that I have
>>>>> almost no experience with OSGi so maybe I'm talking nonsenses). Do
>
>>>>> you know the reason to "forbid" the installation of an old version
>
>>>>> of an updated bundle?
>>>>
>>>> You can re-install older versions. OBR will *only* update an
>>>> existing bundle if it still satisfies all existing constraints. If
>>>> not, then it will install another version, which will then give you
>
>>>> both versions installed at the same time.
>>>>
>>>> There is no rule forbidding the installation of an old version of
>an
>>>> updated bundle. More than likely, we just aren't speaking the same
>>>> language. Perhaps you can open a JIRA issue with a simple example
>>>> recreating the scenario where you cannot install an older version
>of
>>>> an updated bundle. If so, I'll take a look.
>>>>
>>> mmm... but I can't do that even directly from the felix shell (at
>>> least in Felix bundle version 4.0.2).
>>> I will create an issue as you recommend, but you can recreate the
>>> scenario simply doing:
>>> - Installing a bundle
>>> - Update it with another bundle differing only in its Bundle-Version
>
>>> (I tested with just a qualifier change)
>>> - A try to install again the first bundle will return the original
>>> bundle id (i.e. the updated bundle's id) and the updated version
>will
>>> remain
>>
>> That's because you are using the same location string to install it,
>I
>> suppose and this is a unique key. You need to use a new location
>> string (which by default is the URL you use for your bundle),
>> otherwise you get back the existing bundle. It is not easy to use a
>> different location string from the shell, but is possible from the
>> OSGi API (i.e., BundleContext.installBundle(String, InputStream)).
>>
>> You can do this to see it work: Take your little scenario described
>in
>> the paragraph above and before running the framework make a copy of
>> your initial bundle (just give it a slightly different name), then:
>>
>> 1. Install bundle copy 1.
>> 2. Update it to a bundle differing only in Bundle-Version.
>> 3. Install bundle copy 2.
>>
>> Voila!
>>
>I'm not sure I followed you, but I don't think this is the issue here.
>I'm using different files for each bundle. Here is a more verbose
>output
>of my test:
>
>g! install file:/somepath/test.osgi.bundle_1.0.0.201203312048.jar
>Bundle ID: 402
>g! update 402 file:/somepath/test.osgi.bundle_1.0.0.201203312052.jar
>g! install file:/somepath/test.osgi.bundle_1.0.0.201203312048.jar
>Bundle ID: 402
>
>Note that I use 2 different files for the update
>(test.osgi.bundle_1.0.0.201203312048.jar and
>test.osgi.bundle_1.0.0.201203312052.jar).
>
>If what you mean is that the first (non-updated) version has the same
>path that the one that I'm trying to install later on, that is
>reasonable since they both correspond to the same version/bundle. In
>that case the issue remains, if I need to re-install the bundle
>test.osgi.bundle_1.0.0.201203312048.jar to resolve another one, I will
>not be able to.
>
>> -> richard
>>
>>
>>
>>>
>>> I thought it was the intended behavior.
>>>
>>>> -> richard
>>>>
>>>>>
>>>>>>>
>>>>>>> Note that while I'm using the shell to run my tests, my
>intention
>>>>>>> is to use the OBR API in my code. So the "solution" may be
>>>>>>> available only in the API.
>>>>>>>
>>>>>>> Sorry the mail got so long but I wanted to state my problem as
>>>>>>> clear as possible.
>>>>>>> Thank you for taking the time to read and to answer!
>>>>>>
>>>>>> Still not clear to me what the actual issue is or the solution,
>>>>>> but at a minimum OBR should probably refresh after update.
>>>>>>
>>>>>
>>>>> The issue is that the DexA bundle can't be resolved despite
>>>>> A@1.0.0.2 is available in the repositories. I don't get how
>>>>> refreshing would solve the problem since A@1.0.0.2 can't be
>>>>> installed because A@1.0.0.1 is recognized as an update of it.
>>>>>
>>>>> Thank you again for taking the time to respond to me!
>>>>>
>>>>>> -> richard
>>>>>>
>>>>>>> Kind regards
>>>>>>>
>>>>>>> [1]
>>>>>>>
>http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>For additional commands, e-mail: users-help@felix.apache.org
--
Sent from my phone, excuse my brevity.
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
On 02/04/12 18:32, Richard S. Hall wrote:
> On 4/2/12 17:05, Matias SM wrote:
>>
>>
>> On 02/04/12 17:31, Richard S. Hall wrote:
>>> On 4/2/12 15:42, Matias SM wrote:
>>>> Thank you for your answer Richard, please see my comments inline:
>>>>
>>>> On 02/04/12 14:40, Richard S. Hall wrote:
>>>>> On 4/1/12 12:32, Matias SM wrote:
>>>>>> Hi everybody,
>>>>>> I'm using OBR to help me resolve bundle deployment. Everything
>>>>>> works great and as expected but I'm facing a situation I don't
>>>>>> know how to solve.
>>>>>>
>>>>>> ---------------------------------------
>>>>>> Here is my test scenario:
>>>>>> I have the following bundles in an OBR repository:
>>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>>>>> "p.a" version: 1)
>>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
>>>>>> "p.a" version: 1)
>>>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>>>>> version: [1 , 2) )
>>>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package:
>>>>>> "p.a" version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2,
>>>>>> 1.0.0.2] )
>>>>>>
>>>>>> Then my test runs as follows:
>>>>>> g! deploy -s DA
>>>>>> ==> this also deploys A version 1.0.0.2 (I guess because it
>>>>>> is the "newer" bundle that exports "pa" version 1)
>>>>>>
>>>>>> g! deploy -s A@1.0.0.1
>>>>>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>>>>>
>>>>>> First "issue", if I run:
>>>>>> g!deploy -s A@1.0.0.2
>>>>>> ==> then OBR executes successfully but A@1.0.0.2 is not
>>>>>> installed (since there is an "updated" version of it already
>>>>>> resolved). I know this is the expected behavior, but I would like
>>>>>> to be able to deploy A@1.0.0.2
>>>>>
>>>>> It seems like OBR should probably be performing a refresh after it
>>>>> does an update, so there isn't an older version hanging around.
>>>>>
>>>>>>
>>>>>> Second (and worse) issue, if I now run:
>>>>>> g!refresh
>>>>>> ==> so A@1.0.0.2 is completely uninstalled from the framework
>>>>>> And then:
>>>>>> g!deploy -s DexA
>>>>>> ==> this deployment __fails__ because A@1.0.0.2 can't be
>>>>>> reinstalled in the framework!!
>>>>>
>>>>> Not sure why that would be. Are you seeing some sort of error?
>>>>>
>>>>
>>>> I think that the "problem" here is that to be able to update the
>>>> dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that
>>>> was deployed in step 2). I don't think this should be a valid thing
>>>> to do.
>>>
>>> Still seems like it should be possible for OBR to deploy DexA by
>>> updating 1.0.0.1 to 1.0.0.2.
>>
>> Wouldn't that break the request that bundle A@1.0.0.1 is deployed
>> (step 2 in test)?
>
> No. OBR doesn't keep some set of "desired deployed bundles" or
> anything like that...it isn't that sophisticated. It simply tries to
> deploy bundles given the current context of the framework. So, the
> fact that you told OBR to deploy foo in some previous request has no
> bearing on subsequent requests other than the fact that it impacts the
> set of installed bundles from which it starts to perform its
> operation...but that is no different than if you installed a given
> bundle manually and didn't use OBR at all.
>
Ok, now I understand your point. Though I can see that this behavior may
lead to some issues if bundle A@1.0.0.1 has some kind of functionality
other than defining classes to export.
>>
>>>
>>>>
>>>>>> ---------------------------------------
>>>>>>
>>>>>> In the OBR project web page [1] can be read:
>>>>>> "OBR's deployment algorithm appears simple at first glance, but
>>>>>> it is actually somewhat complex due to the nature of deploying
>>>>>> independently developed bundles. For example, in an ideal world,
>>>>>> if an update for a bundle is made available, then updates for all
>>>>>> of the bundles satisfying its dependencies are also made
>>>>>> available. Unfortunately, this may not be the case, thus the
>>>>>> deployment algorithm might have to install new bundles during an
>>>>>> update to satisfy either new dependencies or updated dependencies
>>>>>> that can no longer be satisfied by existing local bundles. In
>>>>>> response to this type of scenario, ___the OBR deployment
>>>>>> algorithm tries to favor updating existing bundles, if possible,
>>>>>> as opposed to installing new bundles to satisfy dependencies.____"
>>>>>>
>>>>>> I don't fully understand this explanation but I get that the
>>>>>> described behavior is as intended.
>>>>>
>>>>> Not sure which part you don't understand.
>>>>
>>>> What I don't understand is how the need to favor updating existing
>>>> bundles is concluded from the problem stated in the previous
>>>> sentences. It is not clear to me the relation between the need to
>>>> "install new bundles during an update" and the algorithm that
>>>> "tries to favor updating existing bundles instead of installing new
>>>> ones".
>>>
>>> Ok, I see your point now. No, the one doesn't necessarily follow the
>>> other. The reason to favor updating existing bundles is the reason I
>>> gave below.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> My questions are:
>>>>>> 1- Is there a way to force the installation of different bundle
>>>>>> versions (instead of the update of "older" ones) when deploying
>>>>>> through OBR?
>>>>>
>>>>> No, I don't think so.
>>>>>
>>>>>> 2- What kind of issues may this behavior (installation of
>>>>>> different versions) rise? (this is not considering the "problem"
>>>>>> of having a lot of bundles installed)
>>>>>
>>>>> Lots of providers is generally a bad thing since it creates many
>>>>> partitions in the overall class spaces of the bundles, meaning
>>>>> that collaboration among them becomes limited to little islands of
>>>>> bundles that happen to be using the same same providers.
>>>>>
>>>> I understand. But updating the bundles may lead to the problem I
>>>> presented, where a bundle can't be resolved despite all necessary
>>>> resources are available.
>>>>
>>>> I know that this behavior is not defined by OBR but OSGi in
>>>> general. But I don't understand why once a bundle is updated, an
>>>> older version of it can't be re-installed so a bundle depending on
>>>> it can be successfully resolved. I think that allowing this may
>>>> help to avoid problems like the one presented (note that I have
>>>> almost no experience with OSGi so maybe I'm talking nonsenses). Do
>>>> you know the reason to "forbid" the installation of an old version
>>>> of an updated bundle?
>>>
>>> You can re-install older versions. OBR will *only* update an
>>> existing bundle if it still satisfies all existing constraints. If
>>> not, then it will install another version, which will then give you
>>> both versions installed at the same time.
>>>
>>> There is no rule forbidding the installation of an old version of an
>>> updated bundle. More than likely, we just aren't speaking the same
>>> language. Perhaps you can open a JIRA issue with a simple example
>>> recreating the scenario where you cannot install an older version of
>>> an updated bundle. If so, I'll take a look.
>>>
>> mmm... but I can't do that even directly from the felix shell (at
>> least in Felix bundle version 4.0.2).
>> I will create an issue as you recommend, but you can recreate the
>> scenario simply doing:
>> - Installing a bundle
>> - Update it with another bundle differing only in its Bundle-Version
>> (I tested with just a qualifier change)
>> - A try to install again the first bundle will return the original
>> bundle id (i.e. the updated bundle's id) and the updated version will
>> remain
>
> That's because you are using the same location string to install it, I
> suppose and this is a unique key. You need to use a new location
> string (which by default is the URL you use for your bundle),
> otherwise you get back the existing bundle. It is not easy to use a
> different location string from the shell, but is possible from the
> OSGi API (i.e., BundleContext.installBundle(String, InputStream)).
>
> You can do this to see it work: Take your little scenario described in
> the paragraph above and before running the framework make a copy of
> your initial bundle (just give it a slightly different name), then:
>
> 1. Install bundle copy 1.
> 2. Update it to a bundle differing only in Bundle-Version.
> 3. Install bundle copy 2.
>
> Voila!
>
I'm not sure I followed you, but I don't think this is the issue here.
I'm using different files for each bundle. Here is a more verbose output
of my test:
g! install file:/somepath/test.osgi.bundle_1.0.0.201203312048.jar
Bundle ID: 402
g! update 402 file:/somepath/test.osgi.bundle_1.0.0.201203312052.jar
g! install file:/somepath/test.osgi.bundle_1.0.0.201203312048.jar
Bundle ID: 402
Note that I use 2 different files for the update
(test.osgi.bundle_1.0.0.201203312048.jar and
test.osgi.bundle_1.0.0.201203312052.jar).
If what you mean is that the first (non-updated) version has the same
path that the one that I'm trying to install later on, that is
reasonable since they both correspond to the same version/bundle. In
that case the issue remains, if I need to re-install the bundle
test.osgi.bundle_1.0.0.201203312048.jar to resolve another one, I will
not be able to.
> -> richard
>
>
>
>>
>> I thought it was the intended behavior.
>>
>>> -> richard
>>>
>>>>
>>>>>>
>>>>>> Note that while I'm using the shell to run my tests, my intention
>>>>>> is to use the OBR API in my code. So the "solution" may be
>>>>>> available only in the API.
>>>>>>
>>>>>> Sorry the mail got so long but I wanted to state my problem as
>>>>>> clear as possible.
>>>>>> Thank you for taking the time to read and to answer!
>>>>>
>>>>> Still not clear to me what the actual issue is or the solution,
>>>>> but at a minimum OBR should probably refresh after update.
>>>>>
>>>>
>>>> The issue is that the DexA bundle can't be resolved despite
>>>> A@1.0.0.2 is available in the repositories. I don't get how
>>>> refreshing would solve the problem since A@1.0.0.2 can't be
>>>> installed because A@1.0.0.1 is recognized as an update of it.
>>>>
>>>> Thank you again for taking the time to respond to me!
>>>>
>>>>> -> richard
>>>>>
>>>>>> Kind regards
>>>>>>
>>>>>> [1]
>>>>>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>>>>>>
>>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/2/12 17:05, Matias SM wrote:
>
>
> On 02/04/12 17:31, Richard S. Hall wrote:
>> On 4/2/12 15:42, Matias SM wrote:
>>> Thank you for your answer Richard, please see my comments inline:
>>>
>>> On 02/04/12 14:40, Richard S. Hall wrote:
>>>> On 4/1/12 12:32, Matias SM wrote:
>>>>> Hi everybody,
>>>>> I'm using OBR to help me resolve bundle deployment. Everything
>>>>> works great and as expected but I'm facing a situation I don't
>>>>> know how to solve.
>>>>>
>>>>> ---------------------------------------
>>>>> Here is my test scenario:
>>>>> I have the following bundles in an OBR repository:
>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>>>> "p.a" version: 1)
>>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
>>>>> "p.a" version: 1)
>>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>>>> version: [1 , 2) )
>>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>>>>
>>>>> Then my test runs as follows:
>>>>> g! deploy -s DA
>>>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>>>> the "newer" bundle that exports "pa" version 1)
>>>>>
>>>>> g! deploy -s A@1.0.0.1
>>>>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>>>>
>>>>> First "issue", if I run:
>>>>> g!deploy -s A@1.0.0.2
>>>>> ==> then OBR executes successfully but A@1.0.0.2 is not
>>>>> installed (since there is an "updated" version of it already
>>>>> resolved). I know this is the expected behavior, but I would like
>>>>> to be able to deploy A@1.0.0.2
>>>>
>>>> It seems like OBR should probably be performing a refresh after it
>>>> does an update, so there isn't an older version hanging around.
>>>>
>>>>>
>>>>> Second (and worse) issue, if I now run:
>>>>> g!refresh
>>>>> ==> so A@1.0.0.2 is completely uninstalled from the framework
>>>>> And then:
>>>>> g!deploy -s DexA
>>>>> ==> this deployment __fails__ because A@1.0.0.2 can't be
>>>>> reinstalled in the framework!!
>>>>
>>>> Not sure why that would be. Are you seeing some sort of error?
>>>>
>>>
>>> I think that the "problem" here is that to be able to update the
>>> dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that
>>> was deployed in step 2). I don't think this should be a valid thing
>>> to do.
>>
>> Still seems like it should be possible for OBR to deploy DexA by
>> updating 1.0.0.1 to 1.0.0.2.
>
> Wouldn't that break the request that bundle A@1.0.0.1 is deployed
> (step 2 in test)?
No. OBR doesn't keep some set of "desired deployed bundles" or anything
like that...it isn't that sophisticated. It simply tries to deploy
bundles given the current context of the framework. So, the fact that
you told OBR to deploy foo in some previous request has no bearing on
subsequent requests other than the fact that it impacts the set of
installed bundles from which it starts to perform its operation...but
that is no different than if you installed a given bundle manually and
didn't use OBR at all.
>
>>
>>>
>>>>> ---------------------------------------
>>>>>
>>>>> In the OBR project web page [1] can be read:
>>>>> "OBR's deployment algorithm appears simple at first glance, but it
>>>>> is actually somewhat complex due to the nature of deploying
>>>>> independently developed bundles. For example, in an ideal world,
>>>>> if an update for a bundle is made available, then updates for all
>>>>> of the bundles satisfying its dependencies are also made
>>>>> available. Unfortunately, this may not be the case, thus the
>>>>> deployment algorithm might have to install new bundles during an
>>>>> update to satisfy either new dependencies or updated dependencies
>>>>> that can no longer be satisfied by existing local bundles. In
>>>>> response to this type of scenario, ___the OBR deployment algorithm
>>>>> tries to favor updating existing bundles, if possible, as opposed
>>>>> to installing new bundles to satisfy dependencies.____"
>>>>>
>>>>> I don't fully understand this explanation but I get that the
>>>>> described behavior is as intended.
>>>>
>>>> Not sure which part you don't understand.
>>>
>>> What I don't understand is how the need to favor updating existing
>>> bundles is concluded from the problem stated in the previous
>>> sentences. It is not clear to me the relation between the need to
>>> "install new bundles during an update" and the algorithm that "tries
>>> to favor updating existing bundles instead of installing new ones".
>>
>> Ok, I see your point now. No, the one doesn't necessarily follow the
>> other. The reason to favor updating existing bundles is the reason I
>> gave below.
>>
>>>
>>>>
>>>>>
>>>>> My questions are:
>>>>> 1- Is there a way to force the installation of different bundle
>>>>> versions (instead of the update of "older" ones) when deploying
>>>>> through OBR?
>>>>
>>>> No, I don't think so.
>>>>
>>>>> 2- What kind of issues may this behavior (installation of
>>>>> different versions) rise? (this is not considering the "problem"
>>>>> of having a lot of bundles installed)
>>>>
>>>> Lots of providers is generally a bad thing since it creates many
>>>> partitions in the overall class spaces of the bundles, meaning that
>>>> collaboration among them becomes limited to little islands of
>>>> bundles that happen to be using the same same providers.
>>>>
>>> I understand. But updating the bundles may lead to the problem I
>>> presented, where a bundle can't be resolved despite all necessary
>>> resources are available.
>>>
>>> I know that this behavior is not defined by OBR but OSGi in general.
>>> But I don't understand why once a bundle is updated, an older
>>> version of it can't be re-installed so a bundle depending on it can
>>> be successfully resolved. I think that allowing this may help to
>>> avoid problems like the one presented (note that I have almost no
>>> experience with OSGi so maybe I'm talking nonsenses). Do you know
>>> the reason to "forbid" the installation of an old version of an
>>> updated bundle?
>>
>> You can re-install older versions. OBR will *only* update an existing
>> bundle if it still satisfies all existing constraints. If not, then
>> it will install another version, which will then give you both
>> versions installed at the same time.
>>
>> There is no rule forbidding the installation of an old version of an
>> updated bundle. More than likely, we just aren't speaking the same
>> language. Perhaps you can open a JIRA issue with a simple example
>> recreating the scenario where you cannot install an older version of
>> an updated bundle. If so, I'll take a look.
>>
> mmm... but I can't do that even directly from the felix shell (at
> least in Felix bundle version 4.0.2).
> I will create an issue as you recommend, but you can recreate the
> scenario simply doing:
> - Installing a bundle
> - Update it with another bundle differing only in its Bundle-Version
> (I tested with just a qualifier change)
> - A try to install again the first bundle will return the original
> bundle id (i.e. the updated bundle's id) and the updated version will
> remain
That's because you are using the same location string to install it, I
suppose and this is a unique key. You need to use a new location string
(which by default is the URL you use for your bundle), otherwise you get
back the existing bundle. It is not easy to use a different location
string from the shell, but is possible from the OSGi API (i.e.,
BundleContext.installBundle(String, InputStream)).
You can do this to see it work: Take your little scenario described in
the paragraph above and before running the framework make a copy of your
initial bundle (just give it a slightly different name), then:
1. Install bundle copy 1.
2. Update it to a bundle differing only in Bundle-Version.
3. Install bundle copy 2.
Voila!
-> richard
>
> I thought it was the intended behavior.
>
>> -> richard
>>
>>>
>>>>>
>>>>> Note that while I'm using the shell to run my tests, my intention
>>>>> is to use the OBR API in my code. So the "solution" may be
>>>>> available only in the API.
>>>>>
>>>>> Sorry the mail got so long but I wanted to state my problem as
>>>>> clear as possible.
>>>>> Thank you for taking the time to read and to answer!
>>>>
>>>> Still not clear to me what the actual issue is or the solution, but
>>>> at a minimum OBR should probably refresh after update.
>>>>
>>>
>>> The issue is that the DexA bundle can't be resolved despite
>>> A@1.0.0.2 is available in the repositories. I don't get how
>>> refreshing would solve the problem since A@1.0.0.2 can't be
>>> installed because A@1.0.0.1 is recognized as an update of it.
>>>
>>> Thank you again for taking the time to respond to me!
>>>
>>>> -> richard
>>>>
>>>>> Kind regards
>>>>>
>>>>> [1]
>>>>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>>>>>
>>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
On 02/04/12 17:31, Richard S. Hall wrote:
> On 4/2/12 15:42, Matias SM wrote:
>> Thank you for your answer Richard, please see my comments inline:
>>
>> On 02/04/12 14:40, Richard S. Hall wrote:
>>> On 4/1/12 12:32, Matias SM wrote:
>>>> Hi everybody,
>>>> I'm using OBR to help me resolve bundle deployment. Everything
>>>> works great and as expected but I'm facing a situation I don't know
>>>> how to solve.
>>>>
>>>> ---------------------------------------
>>>> Here is my test scenario:
>>>> I have the following bundles in an OBR repository:
>>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>>> "p.a" version: 1)
>>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
>>>> "p.a" version: 1)
>>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>>> version: [1 , 2) )
>>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>>>
>>>> Then my test runs as follows:
>>>> g! deploy -s DA
>>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>>> the "newer" bundle that exports "pa" version 1)
>>>>
>>>> g! deploy -s A@1.0.0.1
>>>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>>>
>>>> First "issue", if I run:
>>>> g!deploy -s A@1.0.0.2
>>>> ==> then OBR executes successfully but A@1.0.0.2 is not
>>>> installed (since there is an "updated" version of it already
>>>> resolved). I know this is the expected behavior, but I would like
>>>> to be able to deploy A@1.0.0.2
>>>
>>> It seems like OBR should probably be performing a refresh after it
>>> does an update, so there isn't an older version hanging around.
>>>
>>>>
>>>> Second (and worse) issue, if I now run:
>>>> g!refresh
>>>> ==> so A@1.0.0.2 is completely uninstalled from the framework
>>>> And then:
>>>> g!deploy -s DexA
>>>> ==> this deployment __fails__ because A@1.0.0.2 can't be
>>>> reinstalled in the framework!!
>>>
>>> Not sure why that would be. Are you seeing some sort of error?
>>>
>>
>> I think that the "problem" here is that to be able to update the
>> dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that
>> was deployed in step 2). I don't think this should be a valid thing
>> to do.
>
> Still seems like it should be possible for OBR to deploy DexA by
> updating 1.0.0.1 to 1.0.0.2.
Wouldn't that break the request that bundle A@1.0.0.1 is deployed (step
2 in test)?
>
>>
>>>> ---------------------------------------
>>>>
>>>> In the OBR project web page [1] can be read:
>>>> "OBR's deployment algorithm appears simple at first glance, but it
>>>> is actually somewhat complex due to the nature of deploying
>>>> independently developed bundles. For example, in an ideal world, if
>>>> an update for a bundle is made available, then updates for all of
>>>> the bundles satisfying its dependencies are also made available.
>>>> Unfortunately, this may not be the case, thus the deployment
>>>> algorithm might have to install new bundles during an update to
>>>> satisfy either new dependencies or updated dependencies that can no
>>>> longer be satisfied by existing local bundles. In response to this
>>>> type of scenario, ___the OBR deployment algorithm tries to favor
>>>> updating existing bundles, if possible, as opposed to installing
>>>> new bundles to satisfy dependencies.____"
>>>>
>>>> I don't fully understand this explanation but I get that the
>>>> described behavior is as intended.
>>>
>>> Not sure which part you don't understand.
>>
>> What I don't understand is how the need to favor updating existing
>> bundles is concluded from the problem stated in the previous
>> sentences. It is not clear to me the relation between the need to
>> "install new bundles during an update" and the algorithm that "tries
>> to favor updating existing bundles instead of installing new ones".
>
> Ok, I see your point now. No, the one doesn't necessarily follow the
> other. The reason to favor updating existing bundles is the reason I
> gave below.
>
>>
>>>
>>>>
>>>> My questions are:
>>>> 1- Is there a way to force the installation of different bundle
>>>> versions (instead of the update of "older" ones) when deploying
>>>> through OBR?
>>>
>>> No, I don't think so.
>>>
>>>> 2- What kind of issues may this behavior (installation of different
>>>> versions) rise? (this is not considering the "problem" of having a
>>>> lot of bundles installed)
>>>
>>> Lots of providers is generally a bad thing since it creates many
>>> partitions in the overall class spaces of the bundles, meaning that
>>> collaboration among them becomes limited to little islands of
>>> bundles that happen to be using the same same providers.
>>>
>> I understand. But updating the bundles may lead to the problem I
>> presented, where a bundle can't be resolved despite all necessary
>> resources are available.
>>
>> I know that this behavior is not defined by OBR but OSGi in general.
>> But I don't understand why once a bundle is updated, an older version
>> of it can't be re-installed so a bundle depending on it can be
>> successfully resolved. I think that allowing this may help to avoid
>> problems like the one presented (note that I have almost no
>> experience with OSGi so maybe I'm talking nonsenses). Do you know the
>> reason to "forbid" the installation of an old version of an updated
>> bundle?
>
> You can re-install older versions. OBR will *only* update an existing
> bundle if it still satisfies all existing constraints. If not, then it
> will install another version, which will then give you both versions
> installed at the same time.
>
> There is no rule forbidding the installation of an old version of an
> updated bundle. More than likely, we just aren't speaking the same
> language. Perhaps you can open a JIRA issue with a simple example
> recreating the scenario where you cannot install an older version of
> an updated bundle. If so, I'll take a look.
>
mmm... but I can't do that even directly from the felix shell (at least
in Felix bundle version 4.0.2).
I will create an issue as you recommend, but you can recreate the
scenario simply doing:
- Installing a bundle
- Update it with another bundle differing only in its Bundle-Version (I
tested with just a qualifier change)
- A try to install again the first bundle will return the original
bundle id (i.e. the updated bundle's id) and the updated version will
remain
I thought it was the intended behavior.
> -> richard
>
>>
>>>>
>>>> Note that while I'm using the shell to run my tests, my intention
>>>> is to use the OBR API in my code. So the "solution" may be
>>>> available only in the API.
>>>>
>>>> Sorry the mail got so long but I wanted to state my problem as
>>>> clear as possible.
>>>> Thank you for taking the time to read and to answer!
>>>
>>> Still not clear to me what the actual issue is or the solution, but
>>> at a minimum OBR should probably refresh after update.
>>>
>>
>> The issue is that the DexA bundle can't be resolved despite A@1.0.0.2
>> is available in the repositories. I don't get how refreshing would
>> solve the problem since A@1.0.0.2 can't be installed because
>> A@1.0.0.1 is recognized as an update of it.
>>
>> Thank you again for taking the time to respond to me!
>>
>>> -> richard
>>>
>>>> Kind regards
>>>>
>>>> [1]
>>>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>>>>
>>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/2/12 15:42, Matias SM wrote:
> Thank you for your answer Richard, please see my comments inline:
>
> On 02/04/12 14:40, Richard S. Hall wrote:
>> On 4/1/12 12:32, Matias SM wrote:
>>> Hi everybody,
>>> I'm using OBR to help me resolve bundle deployment. Everything works
>>> great and as expected but I'm facing a situation I don't know how to
>>> solve.
>>>
>>> ---------------------------------------
>>> Here is my test scenario:
>>> I have the following bundles in an OBR repository:
>>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>>> "p.a" version: 1)
>>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package:
>>> "p.a" version: 1)
>>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>>> version: [1 , 2) )
>>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>>
>>> Then my test runs as follows:
>>> g! deploy -s DA
>>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>>> the "newer" bundle that exports "pa" version 1)
>>>
>>> g! deploy -s A@1.0.0.1
>>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>>
>>> First "issue", if I run:
>>> g!deploy -s A@1.0.0.2
>>> ==> then OBR executes successfully but A@1.0.0.2 is not
>>> installed (since there is an "updated" version of it already
>>> resolved). I know this is the expected behavior, but I would like to
>>> be able to deploy A@1.0.0.2
>>
>> It seems like OBR should probably be performing a refresh after it
>> does an update, so there isn't an older version hanging around.
>>
>>>
>>> Second (and worse) issue, if I now run:
>>> g!refresh
>>> ==> so A@1.0.0.2 is completely uninstalled from the framework
>>> And then:
>>> g!deploy -s DexA
>>> ==> this deployment __fails__ because A@1.0.0.2 can't be
>>> reinstalled in the framework!!
>>
>> Not sure why that would be. Are you seeing some sort of error?
>>
>
> I think that the "problem" here is that to be able to update the
> dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was
> deployed in step 2). I don't think this should be a valid thing to do.
Still seems like it should be possible for OBR to deploy DexA by
updating 1.0.0.1 to 1.0.0.2.
>
>>> ---------------------------------------
>>>
>>> In the OBR project web page [1] can be read:
>>> "OBR's deployment algorithm appears simple at first glance, but it
>>> is actually somewhat complex due to the nature of deploying
>>> independently developed bundles. For example, in an ideal world, if
>>> an update for a bundle is made available, then updates for all of
>>> the bundles satisfying its dependencies are also made available.
>>> Unfortunately, this may not be the case, thus the deployment
>>> algorithm might have to install new bundles during an update to
>>> satisfy either new dependencies or updated dependencies that can no
>>> longer be satisfied by existing local bundles. In response to this
>>> type of scenario, ___the OBR deployment algorithm tries to favor
>>> updating existing bundles, if possible, as opposed to installing new
>>> bundles to satisfy dependencies.____"
>>>
>>> I don't fully understand this explanation but I get that the
>>> described behavior is as intended.
>>
>> Not sure which part you don't understand.
>
> What I don't understand is how the need to favor updating existing
> bundles is concluded from the problem stated in the previous
> sentences. It is not clear to me the relation between the need to
> "install new bundles during an update" and the algorithm that "tries
> to favor updating existing bundles instead of installing new ones".
Ok, I see your point now. No, the one doesn't necessarily follow the
other. The reason to favor updating existing bundles is the reason I
gave below.
>
>>
>>>
>>> My questions are:
>>> 1- Is there a way to force the installation of different bundle
>>> versions (instead of the update of "older" ones) when deploying
>>> through OBR?
>>
>> No, I don't think so.
>>
>>> 2- What kind of issues may this behavior (installation of different
>>> versions) rise? (this is not considering the "problem" of having a
>>> lot of bundles installed)
>>
>> Lots of providers is generally a bad thing since it creates many
>> partitions in the overall class spaces of the bundles, meaning that
>> collaboration among them becomes limited to little islands of bundles
>> that happen to be using the same same providers.
>>
> I understand. But updating the bundles may lead to the problem I
> presented, where a bundle can't be resolved despite all necessary
> resources are available.
>
> I know that this behavior is not defined by OBR but OSGi in general.
> But I don't understand why once a bundle is updated, an older version
> of it can't be re-installed so a bundle depending on it can be
> successfully resolved. I think that allowing this may help to avoid
> problems like the one presented (note that I have almost no experience
> with OSGi so maybe I'm talking nonsenses). Do you know the reason to
> "forbid" the installation of an old version of an updated bundle?
You can re-install older versions. OBR will *only* update an existing
bundle if it still satisfies all existing constraints. If not, then it
will install another version, which will then give you both versions
installed at the same time.
There is no rule forbidding the installation of an old version of an
updated bundle. More than likely, we just aren't speaking the same
language. Perhaps you can open a JIRA issue with a simple example
recreating the scenario where you cannot install an older version of an
updated bundle. If so, I'll take a look.
-> richard
>
>>>
>>> Note that while I'm using the shell to run my tests, my intention is
>>> to use the OBR API in my code. So the "solution" may be available
>>> only in the API.
>>>
>>> Sorry the mail got so long but I wanted to state my problem as clear
>>> as possible.
>>> Thank you for taking the time to read and to answer!
>>
>> Still not clear to me what the actual issue is or the solution, but
>> at a minimum OBR should probably refresh after update.
>>
>
> The issue is that the DexA bundle can't be resolved despite A@1.0.0.2
> is available in the repositories. I don't get how refreshing would
> solve the problem since A@1.0.0.2 can't be installed because A@1.0.0.1
> is recognized as an update of it.
>
> Thank you again for taking the time to respond to me!
>
>> -> richard
>>
>>> Kind regards
>>>
>>> [1]
>>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OBR and automatic bundle update
Posted by Matias SM <ma...@yahoo.com.ar>.
Thank you for your answer Richard, please see my comments inline:
On 02/04/12 14:40, Richard S. Hall wrote:
> On 4/1/12 12:32, Matias SM wrote:
>> Hi everybody,
>> I'm using OBR to help me resolve bundle deployment. Everything works
>> great and as expected but I'm facing a situation I don't know how to
>> solve.
>>
>> ---------------------------------------
>> Here is my test scenario:
>> I have the following bundles in an OBR repository:
>> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package:
>> "p.a" version: 1)
>> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
>> version: 1)
>> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
>> version: [1 , 2) )
>> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
>> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>>
>> Then my test runs as follows:
>> g! deploy -s DA
>> ==> this also deploys A version 1.0.0.2 (I guess because it is
>> the "newer" bundle that exports "pa" version 1)
>>
>> g! deploy -s A@1.0.0.1
>> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>>
>> First "issue", if I run:
>> g!deploy -s A@1.0.0.2
>> ==> then OBR executes successfully but A@1.0.0.2 is not installed
>> (since there is an "updated" version of it already resolved). I know
>> this is the expected behavior, but I would like to be able to deploy
>> A@1.0.0.2
>
> It seems like OBR should probably be performing a refresh after it
> does an update, so there isn't an older version hanging around.
>
>>
>> Second (and worse) issue, if I now run:
>> g!refresh
>> ==> so A@1.0.0.2 is completely uninstalled from the framework
>> And then:
>> g!deploy -s DexA
>> ==> this deployment __fails__ because A@1.0.0.2 can't be
>> reinstalled in the framework!!
>
> Not sure why that would be. Are you seeing some sort of error?
>
I think that the "problem" here is that to be able to update the
dependency again to A@1.0.0.2, OBR should withhold A@1.0.0.1 (that was
deployed in step 2). I don't think this should be a valid thing to do.
>> ---------------------------------------
>>
>> In the OBR project web page [1] can be read:
>> "OBR's deployment algorithm appears simple at first glance, but it is
>> actually somewhat complex due to the nature of deploying
>> independently developed bundles. For example, in an ideal world, if
>> an update for a bundle is made available, then updates for all of the
>> bundles satisfying its dependencies are also made available.
>> Unfortunately, this may not be the case, thus the deployment
>> algorithm might have to install new bundles during an update to
>> satisfy either new dependencies or updated dependencies that can no
>> longer be satisfied by existing local bundles. In response to this
>> type of scenario, ___the OBR deployment algorithm tries to favor
>> updating existing bundles, if possible, as opposed to installing new
>> bundles to satisfy dependencies.____"
>>
>> I don't fully understand this explanation but I get that the
>> described behavior is as intended.
>
> Not sure which part you don't understand.
What I don't understand is how the need to favor updating existing
bundles is concluded from the problem stated in the previous sentences.
It is not clear to me the relation between the need to "install new
bundles during an update" and the algorithm that "tries to favor
updating existing bundles instead of installing new ones".
>
>>
>> My questions are:
>> 1- Is there a way to force the installation of different bundle
>> versions (instead of the update of "older" ones) when deploying
>> through OBR?
>
> No, I don't think so.
>
>> 2- What kind of issues may this behavior (installation of different
>> versions) rise? (this is not considering the "problem" of having a
>> lot of bundles installed)
>
> Lots of providers is generally a bad thing since it creates many
> partitions in the overall class spaces of the bundles, meaning that
> collaboration among them becomes limited to little islands of bundles
> that happen to be using the same same providers.
>
I understand. But updating the bundles may lead to the problem I
presented, where a bundle can't be resolved despite all necessary
resources are available.
I know that this behavior is not defined by OBR but OSGi in general. But
I don't understand why once a bundle is updated, an older version of it
can't be re-installed so a bundle depending on it can be successfully
resolved. I think that allowing this may help to avoid problems like the
one presented (note that I have almost no experience with OSGi so maybe
I'm talking nonsenses). Do you know the reason to "forbid" the
installation of an old version of an updated bundle?
>>
>> Note that while I'm using the shell to run my tests, my intention is
>> to use the OBR API in my code. So the "solution" may be available
>> only in the API.
>>
>> Sorry the mail got so long but I wanted to state my problem as clear
>> as possible.
>> Thank you for taking the time to read and to answer!
>
> Still not clear to me what the actual issue is or the solution, but at
> a minimum OBR should probably refresh after update.
>
The issue is that the DexA bundle can't be resolved despite A@1.0.0.2 is
available in the repositories. I don't get how refreshing would solve
the problem since A@1.0.0.2 can't be installed because A@1.0.0.1 is
recognized as an update of it.
Thank you again for taking the time to respond to me!
> -> richard
>
>> Kind regards
>>
>> [1]
>> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>>
>>
Re: OBR and automatic bundle update
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/1/12 12:32, Matias SM wrote:
> Hi everybody,
> I'm using OBR to help me resolve bundle deployment. Everything works
> great and as expected but I'm facing a situation I don't know how to
> solve.
>
> ---------------------------------------
> Here is my test scenario:
> I have the following bundles in an OBR repository:
> * SymbolicName: A | Bundle-Version: 1.0.0.1 | exports: (package: "p.a"
> version: 1)
> * SymbolicName: A | Bundle-Version: 1.0.0.2| exports: (package: "p.a"
> version: 1)
> * SymbolicName: DA | Bundle-Version: 1| depends: (package: "p.a"
> version: [1 , 2) )
> * SymbolicName: DexA | Bundle-Version: 1| depends: (package: "p.a"
> version: [1 , 2) ) and (bundle: "A" version: [1.0.0.2, 1.0.0.2] )
>
> Then my test runs as follows:
> g! deploy -s DA
> ==> this also deploys A version 1.0.0.2 (I guess because it is the
> "newer" bundle that exports "pa" version 1)
>
> g! deploy -s A@1.0.0.1
> ==> this __updates__ the previously deployed A (version 1.0.0.2)
>
> First "issue", if I run:
> g!deploy -s A@1.0.0.2
> ==> then OBR executes successfully but A@1.0.0.2 is not installed
> (since there is an "updated" version of it already resolved). I know
> this is the expected behavior, but I would like to be able to deploy
> A@1.0.0.2
It seems like OBR should probably be performing a refresh after it does
an update, so there isn't an older version hanging around.
>
> Second (and worse) issue, if I now run:
> g!refresh
> ==> so A@1.0.0.2 is completely uninstalled from the framework
> And then:
> g!deploy -s DexA
> ==> this deployment __fails__ because A@1.0.0.2 can't be
> reinstalled in the framework!!
Not sure why that would be. Are you seeing some sort of error?
> ---------------------------------------
>
> In the OBR project web page [1] can be read:
> "OBR's deployment algorithm appears simple at first glance, but it is
> actually somewhat complex due to the nature of deploying independently
> developed bundles. For example, in an ideal world, if an update for a
> bundle is made available, then updates for all of the bundles
> satisfying its dependencies are also made available. Unfortunately,
> this may not be the case, thus the deployment algorithm might have to
> install new bundles during an update to satisfy either new
> dependencies or updated dependencies that can no longer be satisfied
> by existing local bundles. In response to this type of scenario,
> ___the OBR deployment algorithm tries to favor updating existing
> bundles, if possible, as opposed to installing new bundles to satisfy
> dependencies.____"
>
> I don't fully understand this explanation but I get that the described
> behavior is as intended.
Not sure which part you don't understand.
>
> My questions are:
> 1- Is there a way to force the installation of different bundle
> versions (instead of the update of "older" ones) when deploying
> through OBR?
No, I don't think so.
> 2- What kind of issues may this behavior (installation of different
> versions) rise? (this is not considering the "problem" of having a lot
> of bundles installed)
Lots of providers is generally a bad thing since it creates many
partitions in the overall class spaces of the bundles, meaning that
collaboration among them becomes limited to little islands of bundles
that happen to be using the same same providers.
>
> Note that while I'm using the shell to run my tests, my intention is
> to use the OBR API in my code. So the "solution" may be available only
> in the API.
>
> Sorry the mail got so long but I wanted to state my problem as clear
> as possible.
> Thank you for taking the time to read and to answer!
Still not clear to me what the actual issue is or the solution, but at a
minimum OBR should probably refresh after update.
-> richard
> Kind regards
>
> [1]
> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html#ApacheFelixOSGiBundleRepository-OBRServiceAPI
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org