You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by San,
Matías <ma...@yahoo.com.ar> on 2012/02/21 01:05:57 UTC
Refreshed bundle still wired to uninstalled one
Hi everybody,
As the subject of this mail states, I'm facing a situation where a
bundle stays wired to an uninstalled one even after refreshing the
former.
I checked that no other bundle stays wired to the uninstalled one.
I'm using Apache Felix version 4.0.2.
I'm new in the OSGi world so I'm not sure if that is an expected
behavior.
Here are the results of executing "lb" and "inspect requirement
osgi.wiring.package" with my specific bundles (i.e. bundles that are
developed by me for this test):
=================================================================
g! lb
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (4.0.2)
1|Active | 1|Apache Felix Bundle Repository (1.6.6)
2|Active | 1|Apache Felix Gogo Command (0.12.0)
3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
4|Active | 1|Apache Felix Gogo Shell (0.10.0)
31|Active | 1|Apache Felix Http Api (2.2.0)
32|Active | 1|Apache Felix Http Base (2.2.0)
33|Active | 1|Apache Felix Http Bundle (2.2.0)
34|Active | 1|Apache Felix Http Jetty (2.2.0)
35|Active | 1|Apache Felix Web Management Console (3.1.8)
37|Active | 1|OSGi OBR Service API (1.0.0)
68|Resolved | 1|Console (1.0.0)
69|Resolved | 1|Inter (1.0.0)
70|Resolved | 1|Main (1.0.0)
=====================================================================
Here bundles 68, 69 and 70 are the ones I developed (note that bundle 71
was the one that I uninstalled).
=====================================================================
g! inspect requirement osgi.wiring.package 68 69 70
test.osgi.dynload.bundle.echoer.console [68] requires:
------------------------------------------------------
osgi.wiring.package;
(&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0))) resolved by:
osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
test.osgi.dynload.bundle.inter [69]
test.osgi.dynload.bundle.inter [69] requires:
---------------------------------------------
osgi.wiring.package [EMPTY]
test.osgi.dynload.bundle.main [70] requires:
--------------------------------------------
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved by:
osgi.wiring.package; org.osgi.framework 1.6.0 from
org.apache.felix.framework [0]
osgi.wiring.package;
(&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0))) resolved by:
osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
from test.osgi.dynload.bundle.echoer.console [68]
osgi.wiring.package;
(&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)) resolved by:
osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
test.osgi.dynload.bundle.inter [69]
osgi.wiring.package;
(&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0))) resolved by:
osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
from test.osgi.dynload.bundle.runner.thread [71]
=====================================================================
That last line is the one I don't get. For what I know, after refreshing
the bundle 70, the bundle 71 shouldn't be available anymore (then, the
70 shouldn't be able to resolve again).
Has anybody have a clue about what's happening?
Thank you in advance,
Regards
Re: Refreshed bundle still wired to uninstalled one
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/6/12 6:37 PM, Matias SM wrote:
>
>
> On 06/04/12 19:27, Richard S. Hall wrote:
>> On 4/6/12 5:14 PM, Matias SM wrote:
>>>
>>>
>>> On 06/04/12 17:22, Richard S. Hall wrote:
>>>> On 4/6/12 15:09 , Matias SM wrote:
>>>>> Hi Richard,
>>>>> I know I'm resurrecting a little old thread, but I'm reading the
>>>>> core specification (Release 4, Version 4.3) and it says (section
>>>>> 7.3 "Wiring"):
>>>>>
>>>>> /Refreshing happens on a per bundle basis but takes any Bundle
>>>>> Wirings into account that depend on the refreshed bundle. In the
>>>>> previous example, if bundle B is refreshed, it will automatically
>>>>> refresh bundle A because A is wired to B. That is, bundle B is in
>>>>> use by A./
>>>>>
>>>>> So, if I understand correctly, the expected behavior for the test
>>>>> presented at the beginning of this thread is that the bundle 70
>>>>> should change to the installed state after refreshing (bundle 71
>>>>> should be completely uninstalled). Am I missing something?
>>>>
>>>> After refreshing, 70 should change to the INSTALLED state if it has
>>>> mandatory dependencies that cannot be satisfied after 71 is gone.
>>>>
>>>> In the thread below, only bundle 70 was being refreshed, not bundle
>>>> 71, so bundle 71 wasn't going away since it wasn't refreshed. Which
>>>> is why I said the only safe thing to do is a complete refresh
>>>> (i.e., refreshPackages(null)).
>>>
>>> But if I understand correctly the specification extract I just
>>> cited, bundle 71 should also be refreshed since it is wired to
>>> bundle 70. Am I missing something?
>>
>> Yes, you are missing the direction of the wire. If bundle foo imports
>> from bundle bar, then refreshing foo does not require refreshing bar,
>> but refreshing bar does require refreshing foo.
>>
> Ok, I understand. So actually I should refresh bundle 71 but I can't
> since it is uninstalled, and that's why I have to use the no args
> option of refresh.
Exactly.
> Thank you for the clarification Richard!
No problem.
-> richard
> Kind regards
>
>> -> richard
>>
>>>
>>>>
>>>> -> richard
>>
>
> ---------------------------------------------------------------------
> 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: Refreshed bundle still wired to uninstalled one
Posted by Matias SM <ma...@yahoo.com.ar>.
On 06/04/12 19:27, Richard S. Hall wrote:
> On 4/6/12 5:14 PM, Matias SM wrote:
>>
>>
>> On 06/04/12 17:22, Richard S. Hall wrote:
>>> On 4/6/12 15:09 , Matias SM wrote:
>>>> Hi Richard,
>>>> I know I'm resurrecting a little old thread, but I'm reading the
>>>> core specification (Release 4, Version 4.3) and it says (section
>>>> 7.3 "Wiring"):
>>>>
>>>> /Refreshing happens on a per bundle basis but takes any Bundle
>>>> Wirings into account that depend on the refreshed bundle. In the
>>>> previous example, if bundle B is refreshed, it will automatically
>>>> refresh bundle A because A is wired to B. That is, bundle B is in
>>>> use by A./
>>>>
>>>> So, if I understand correctly, the expected behavior for the test
>>>> presented at the beginning of this thread is that the bundle 70
>>>> should change to the installed state after refreshing (bundle 71
>>>> should be completely uninstalled). Am I missing something?
>>>
>>> After refreshing, 70 should change to the INSTALLED state if it has
>>> mandatory dependencies that cannot be satisfied after 71 is gone.
>>>
>>> In the thread below, only bundle 70 was being refreshed, not bundle
>>> 71, so bundle 71 wasn't going away since it wasn't refreshed. Which
>>> is why I said the only safe thing to do is a complete refresh (i.e.,
>>> refreshPackages(null)).
>>
>> But if I understand correctly the specification extract I just cited,
>> bundle 71 should also be refreshed since it is wired to bundle 70. Am
>> I missing something?
>
> Yes, you are missing the direction of the wire. If bundle foo imports
> from bundle bar, then refreshing foo does not require refreshing bar,
> but refreshing bar does require refreshing foo.
>
Ok, I understand. So actually I should refresh bundle 71 but I can't
since it is uninstalled, and that's why I have to use the no args option
of refresh.
Thank you for the clarification Richard!
Kind regards
> -> richard
>
>>
>>>
>>> -> richard
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Refreshed bundle still wired to uninstalled one
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/6/12 5:14 PM, Matias SM wrote:
>
>
> On 06/04/12 17:22, Richard S. Hall wrote:
>> On 4/6/12 15:09 , Matias SM wrote:
>>> Hi Richard,
>>> I know I'm resurrecting a little old thread, but I'm reading the
>>> core specification (Release 4, Version 4.3) and it says (section 7.3
>>> "Wiring"):
>>>
>>> /Refreshing happens on a per bundle basis but takes any Bundle
>>> Wirings into account that depend on the refreshed bundle. In the
>>> previous example, if bundle B is refreshed, it will automatically
>>> refresh bundle A because A is wired to B. That is, bundle B is in
>>> use by A./
>>>
>>> So, if I understand correctly, the expected behavior for the test
>>> presented at the beginning of this thread is that the bundle 70
>>> should change to the installed state after refreshing (bundle 71
>>> should be completely uninstalled). Am I missing something?
>>
>> After refreshing, 70 should change to the INSTALLED state if it has
>> mandatory dependencies that cannot be satisfied after 71 is gone.
>>
>> In the thread below, only bundle 70 was being refreshed, not bundle
>> 71, so bundle 71 wasn't going away since it wasn't refreshed. Which
>> is why I said the only safe thing to do is a complete refresh (i.e.,
>> refreshPackages(null)).
>
> But if I understand correctly the specification extract I just cited,
> bundle 71 should also be refreshed since it is wired to bundle 70. Am
> I missing something?
Yes, you are missing the direction of the wire. If bundle foo imports
from bundle bar, then refreshing foo does not require refreshing bar,
but refreshing bar does require refreshing foo.
-> richard
>
>>
>> -> richard
>>
>>>
>>> Kind regards
>>>
>>> On 21/02/12 12:32, Richard S. Hall wrote:
>>>> On 2/20/12 20:52 , San Martín, Matías wrote:
>>>>> Many thanks Richard for your reply, I didn't know this behavior of
>>>>> the
>>>>> framework.
>>>>
>>>> Well, there is some debate about it. I think Equinox does it
>>>> differently. The only safe thing to do is to completely refresh
>>>> after performing uninstalls and updates, not just selective refreshes.
>>>>
>>>> -> richard
>>>>
>>>>>
>>>>> El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
>>>>>> If you are not refreshing the bundle you uninstalled, then it
>>>>>> doesn't go away. You need to invoke the refresh command with no
>>>>>> args at the Gogo prompt. The framework won't auto refresh a
>>>>>> bundle unless there are no dependencies on it at the time it was
>>>>>> uninstalled.
>>>>>>
>>>>>> The Felix framework will use all available bundles to resolve
>>>>>> dependencies, even ones that are pending removal.
>>>>>>
>>>>>> So, in short, use 'refresh' to really get rid of everything.
>>>>>>
>>>>>> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
>>>>>>
>>>>>>> Hi everybody,
>>>>>>> As the subject of this mail states, I'm facing a situation where a
>>>>>>> bundle stays wired to an uninstalled one even after refreshing the
>>>>>>> former.
>>>>>>> I checked that no other bundle stays wired to the uninstalled one.
>>>>>>> I'm using Apache Felix version 4.0.2.
>>>>>>> I'm new in the OSGi world so I'm not sure if that is an expected
>>>>>>> behavior.
>>>>>>>
>>>>>>> Here are the results of executing "lb" and "inspect requirement
>>>>>>> osgi.wiring.package" with my specific bundles (i.e. bundles that
>>>>>>> are
>>>>>>> developed by me for this test):
>>>>>>>
>>>>>>> =================================================================
>>>>>>> g! lb
>>>>>>> START LEVEL 1
>>>>>>> ID|State |Level|Name
>>>>>>> 0|Active | 0|System Bundle (4.0.2)
>>>>>>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
>>>>>>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
>>>>>>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
>>>>>>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
>>>>>>> 31|Active | 1|Apache Felix Http Api (2.2.0)
>>>>>>> 32|Active | 1|Apache Felix Http Base (2.2.0)
>>>>>>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
>>>>>>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
>>>>>>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
>>>>>>> 37|Active | 1|OSGi OBR Service API (1.0.0)
>>>>>>> 68|Resolved | 1|Console (1.0.0)
>>>>>>> 69|Resolved | 1|Inter (1.0.0)
>>>>>>> 70|Resolved | 1|Main (1.0.0)
>>>>>>> =====================================================================
>>>>>>>
>>>>>>>
>>>>>>> Here bundles 68, 69 and 70 are the ones I developed (note that
>>>>>>> bundle
>>>>>>> 71
>>>>>>> was the one that I uninstalled).
>>>>>>>
>>>>>>> =====================================================================
>>>>>>>
>>>>>>> g! inspect requirement osgi.wiring.package 68 69 70
>>>>>>> test.osgi.dynload.bundle.echoer.console [68] requires:
>>>>>>> ------------------------------------------------------
>>>>>>> osgi.wiring.package;
>>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>>>
>>>>>>> resolved by:
>>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer
>>>>>>> 1.0.0 from
>>>>>>> test.osgi.dynload.bundle.inter [69]
>>>>>>>
>>>>>>> test.osgi.dynload.bundle.inter [69] requires:
>>>>>>> ---------------------------------------------
>>>>>>> osgi.wiring.package [EMPTY]
>>>>>>>
>>>>>>> test.osgi.dynload.bundle.main [70] requires:
>>>>>>> --------------------------------------------
>>>>>>> osgi.wiring.package;
>>>>>>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0))
>>>>>>> resolved
>>>>>>> by:
>>>>>>> osgi.wiring.package; org.osgi.framework 1.6.0 from
>>>>>>> org.apache.felix.framework [0]
>>>>>>> osgi.wiring.package;
>>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>>>
>>>>>>> resolved by:
>>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console
>>>>>>> 1.0.0
>>>>>> >from test.osgi.dynload.bundle.echoer.console [68]
>>>>>>> osgi.wiring.package;
>>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>>>>>>>
>>>>>>> resolved by:
>>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer
>>>>>>> 1.0.0 from
>>>>>>> test.osgi.dynload.bundle.inter [69]
>>>>>>> osgi.wiring.package;
>>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>>>
>>>>>>> resolved by:
>>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread
>>>>>>> 1.0.0
>>>>>> >from test.osgi.dynload.bundle.runner.thread [71]
>>>>>>> =====================================================================
>>>>>>>
>>>>>>>
>>>>>>> That last line is the one I don't get. For what I know, after
>>>>>>> refreshing
>>>>>>> the bundle 70, the bundle 71 shouldn't be available anymore
>>>>>>> (then, the
>>>>>>> 70 shouldn't be able to resolve again).
>>>>>>>
>>>>>>> Has anybody have a clue about what's happening?
>>>>>>> Thank you in advance,
>>>>>>> Regards
>>>>>> --
>>>>>> Sent from my phone, excuse my brevity.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> 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: Refreshed bundle still wired to uninstalled one
Posted by Matias SM <ma...@yahoo.com.ar>.
On 06/04/12 17:22, Richard S. Hall wrote:
> On 4/6/12 15:09 , Matias SM wrote:
>> Hi Richard,
>> I know I'm resurrecting a little old thread, but I'm reading the core
>> specification (Release 4, Version 4.3) and it says (section 7.3
>> "Wiring"):
>>
>> /Refreshing happens on a per bundle basis but takes any Bundle
>> Wirings into account that depend on the refreshed bundle. In the
>> previous example, if bundle B is refreshed, it will automatically
>> refresh bundle A because A is wired to B. That is, bundle B is in
>> use by A./
>>
>> So, if I understand correctly, the expected behavior for the test
>> presented at the beginning of this thread is that the bundle 70
>> should change to the installed state after refreshing (bundle 71
>> should be completely uninstalled). Am I missing something?
>
> After refreshing, 70 should change to the INSTALLED state if it has
> mandatory dependencies that cannot be satisfied after 71 is gone.
>
> In the thread below, only bundle 70 was being refreshed, not bundle
> 71, so bundle 71 wasn't going away since it wasn't refreshed. Which is
> why I said the only safe thing to do is a complete refresh (i.e.,
> refreshPackages(null)).
But if I understand correctly the specification extract I just cited,
bundle 71 should also be refreshed since it is wired to bundle 70. Am I
missing something?
>
> -> richard
>
>>
>> Kind regards
>>
>> On 21/02/12 12:32, Richard S. Hall wrote:
>>> On 2/20/12 20:52 , San Martín, Matías wrote:
>>>> Many thanks Richard for your reply, I didn't know this behavior of the
>>>> framework.
>>>
>>> Well, there is some debate about it. I think Equinox does it
>>> differently. The only safe thing to do is to completely refresh
>>> after performing uninstalls and updates, not just selective refreshes.
>>>
>>> -> richard
>>>
>>>>
>>>> El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
>>>>> If you are not refreshing the bundle you uninstalled, then it
>>>>> doesn't go away. You need to invoke the refresh command with no
>>>>> args at the Gogo prompt. The framework won't auto refresh a bundle
>>>>> unless there are no dependencies on it at the time it was
>>>>> uninstalled.
>>>>>
>>>>> The Felix framework will use all available bundles to resolve
>>>>> dependencies, even ones that are pending removal.
>>>>>
>>>>> So, in short, use 'refresh' to really get rid of everything.
>>>>>
>>>>> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
>>>>>
>>>>>> Hi everybody,
>>>>>> As the subject of this mail states, I'm facing a situation where a
>>>>>> bundle stays wired to an uninstalled one even after refreshing the
>>>>>> former.
>>>>>> I checked that no other bundle stays wired to the uninstalled one.
>>>>>> I'm using Apache Felix version 4.0.2.
>>>>>> I'm new in the OSGi world so I'm not sure if that is an expected
>>>>>> behavior.
>>>>>>
>>>>>> Here are the results of executing "lb" and "inspect requirement
>>>>>> osgi.wiring.package" with my specific bundles (i.e. bundles that are
>>>>>> developed by me for this test):
>>>>>>
>>>>>> =================================================================
>>>>>> g! lb
>>>>>> START LEVEL 1
>>>>>> ID|State |Level|Name
>>>>>> 0|Active | 0|System Bundle (4.0.2)
>>>>>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
>>>>>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
>>>>>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
>>>>>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
>>>>>> 31|Active | 1|Apache Felix Http Api (2.2.0)
>>>>>> 32|Active | 1|Apache Felix Http Base (2.2.0)
>>>>>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
>>>>>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
>>>>>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
>>>>>> 37|Active | 1|OSGi OBR Service API (1.0.0)
>>>>>> 68|Resolved | 1|Console (1.0.0)
>>>>>> 69|Resolved | 1|Inter (1.0.0)
>>>>>> 70|Resolved | 1|Main (1.0.0)
>>>>>> =====================================================================
>>>>>>
>>>>>>
>>>>>> Here bundles 68, 69 and 70 are the ones I developed (note that
>>>>>> bundle
>>>>>> 71
>>>>>> was the one that I uninstalled).
>>>>>>
>>>>>> =====================================================================
>>>>>>
>>>>>> g! inspect requirement osgi.wiring.package 68 69 70
>>>>>> test.osgi.dynload.bundle.echoer.console [68] requires:
>>>>>> ------------------------------------------------------
>>>>>> osgi.wiring.package;
>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>>
>>>>>> resolved by:
>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer
>>>>>> 1.0.0 from
>>>>>> test.osgi.dynload.bundle.inter [69]
>>>>>>
>>>>>> test.osgi.dynload.bundle.inter [69] requires:
>>>>>> ---------------------------------------------
>>>>>> osgi.wiring.package [EMPTY]
>>>>>>
>>>>>> test.osgi.dynload.bundle.main [70] requires:
>>>>>> --------------------------------------------
>>>>>> osgi.wiring.package;
>>>>>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
>>>>>> by:
>>>>>> osgi.wiring.package; org.osgi.framework 1.6.0 from
>>>>>> org.apache.felix.framework [0]
>>>>>> osgi.wiring.package;
>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>>
>>>>>> resolved by:
>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console
>>>>>> 1.0.0
>>>>> >from test.osgi.dynload.bundle.echoer.console [68]
>>>>>> osgi.wiring.package;
>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>>>>>>
>>>>>> resolved by:
>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer
>>>>>> 1.0.0 from
>>>>>> test.osgi.dynload.bundle.inter [69]
>>>>>> osgi.wiring.package;
>>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>>
>>>>>> resolved by:
>>>>>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
>>>>> >from test.osgi.dynload.bundle.runner.thread [71]
>>>>>> =====================================================================
>>>>>>
>>>>>>
>>>>>> That last line is the one I don't get. For what I know, after
>>>>>> refreshing
>>>>>> the bundle 70, the bundle 71 shouldn't be available anymore
>>>>>> (then, the
>>>>>> 70 shouldn't be able to resolve again).
>>>>>>
>>>>>> Has anybody have a clue about what's happening?
>>>>>> Thank you in advance,
>>>>>> Regards
>>>>> --
>>>>> Sent from my phone, excuse my brevity.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Refreshed bundle still wired to uninstalled one
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/6/12 15:09 , Matias SM wrote:
> Hi Richard,
> I know I'm resurrecting a little old thread, but I'm reading the core
> specification (Release 4, Version 4.3) and it says (section 7.3
> "Wiring"):
>
> /Refreshing happens on a per bundle basis but takes any Bundle
> Wirings into account that depend on the refreshed bundle. In the
> previous example, if bundle B is refreshed, it will automatically
> refresh bundle A because A is wired to B. That is, bundle B is in
> use by A./
>
> So, if I understand correctly, the expected behavior for the test
> presented at the beginning of this thread is that the bundle 70 should
> change to the installed state after refreshing (bundle 71 should be
> completely uninstalled). Am I missing something?
After refreshing, 70 should change to the INSTALLED state if it has
mandatory dependencies that cannot be satisfied after 71 is gone.
In the thread below, only bundle 70 was being refreshed, not bundle 71,
so bundle 71 wasn't going away since it wasn't refreshed. Which is why I
said the only safe thing to do is a complete refresh (i.e.,
refreshPackages(null)).
-> richard
>
> Kind regards
>
> On 21/02/12 12:32, Richard S. Hall wrote:
>> On 2/20/12 20:52 , San Martín, Matías wrote:
>>> Many thanks Richard for your reply, I didn't know this behavior of the
>>> framework.
>>
>> Well, there is some debate about it. I think Equinox does it
>> differently. The only safe thing to do is to completely refresh after
>> performing uninstalls and updates, not just selective refreshes.
>>
>> -> richard
>>
>>>
>>> El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
>>>> If you are not refreshing the bundle you uninstalled, then it
>>>> doesn't go away. You need to invoke the refresh command with no
>>>> args at the Gogo prompt. The framework won't auto refresh a bundle
>>>> unless there are no dependencies on it at the time it was uninstalled.
>>>>
>>>> The Felix framework will use all available bundles to resolve
>>>> dependencies, even ones that are pending removal.
>>>>
>>>> So, in short, use 'refresh' to really get rid of everything.
>>>>
>>>> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
>>>>
>>>>> Hi everybody,
>>>>> As the subject of this mail states, I'm facing a situation where a
>>>>> bundle stays wired to an uninstalled one even after refreshing the
>>>>> former.
>>>>> I checked that no other bundle stays wired to the uninstalled one.
>>>>> I'm using Apache Felix version 4.0.2.
>>>>> I'm new in the OSGi world so I'm not sure if that is an expected
>>>>> behavior.
>>>>>
>>>>> Here are the results of executing "lb" and "inspect requirement
>>>>> osgi.wiring.package" with my specific bundles (i.e. bundles that are
>>>>> developed by me for this test):
>>>>>
>>>>> =================================================================
>>>>> g! lb
>>>>> START LEVEL 1
>>>>> ID|State |Level|Name
>>>>> 0|Active | 0|System Bundle (4.0.2)
>>>>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
>>>>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
>>>>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
>>>>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
>>>>> 31|Active | 1|Apache Felix Http Api (2.2.0)
>>>>> 32|Active | 1|Apache Felix Http Base (2.2.0)
>>>>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
>>>>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
>>>>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
>>>>> 37|Active | 1|OSGi OBR Service API (1.0.0)
>>>>> 68|Resolved | 1|Console (1.0.0)
>>>>> 69|Resolved | 1|Inter (1.0.0)
>>>>> 70|Resolved | 1|Main (1.0.0)
>>>>> =====================================================================
>>>>>
>>>>> Here bundles 68, 69 and 70 are the ones I developed (note that bundle
>>>>> 71
>>>>> was the one that I uninstalled).
>>>>>
>>>>> =====================================================================
>>>>> g! inspect requirement osgi.wiring.package 68 69 70
>>>>> test.osgi.dynload.bundle.echoer.console [68] requires:
>>>>> ------------------------------------------------------
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0
>>>>> from
>>>>> test.osgi.dynload.bundle.inter [69]
>>>>>
>>>>> test.osgi.dynload.bundle.inter [69] requires:
>>>>> ---------------------------------------------
>>>>> osgi.wiring.package [EMPTY]
>>>>>
>>>>> test.osgi.dynload.bundle.main [70] requires:
>>>>> --------------------------------------------
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
>>>>> by:
>>>>> osgi.wiring.package; org.osgi.framework 1.6.0 from
>>>>> org.apache.felix.framework [0]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
>>>> >from test.osgi.dynload.bundle.echoer.console [68]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0
>>>>> from
>>>>> test.osgi.dynload.bundle.inter [69]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
>>>> >from test.osgi.dynload.bundle.runner.thread [71]
>>>>> =====================================================================
>>>>>
>>>>> That last line is the one I don't get. For what I know, after
>>>>> refreshing
>>>>> the bundle 70, the bundle 71 shouldn't be available anymore (then,
>>>>> the
>>>>> 70 shouldn't be able to resolve again).
>>>>>
>>>>> Has anybody have a clue about what's happening?
>>>>> Thank you in advance,
>>>>> Regards
>>>> --
>>>> Sent from my phone, excuse my brevity.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Refreshed bundle still wired to uninstalled one
Posted by Matias SM <ma...@yahoo.com.ar>.
On 06/04/12 16:09, Matias SM wrote:
> Hi Richard,
> I know I'm resurrecting a little old thread, but I'm reading the core
> specification (Release 4, Version 4.3) and it says (section 7.3
> "Wiring"):
>
> /Refreshing happens on a per bundle basis but takes any Bundle
> Wirings into account that depend on the refreshed bundle. In the
> previous example, if bundle B is refreshed, it will automatically
> refresh bundle A because A is wired to B. That is, bundle B is in
> use by A./
>
> So, if I understand correctly, the expected behavior for the test
> presented at the beginning of this thread is that the bundle 70 should
> change to the installed state after refreshing (bundle 71 should be
> completely uninstalled). Am I missing something?
>
> Kind regards
>
In addition, in section 9.3.8.3, describing the /refreshBundles/ method,
it specifies:
...
Refreshes the specified bundles. This forces the update (replacement) or
removal of packages exported by the specified bundles.
The technique by which the framework refreshes bundles may vary among
different framework implementations. A permissible implementation is to
stop and restart the framework.
This method returns to the caller immediately and then performs the
following steps on a separate thread:
1 Compute the dependency closure of the specified bundles. If no bundles
are specified, compute the dependency closure of the removal pending
bundles.
2 Each bundle in the dependency closure that is in the ACTIVE state will
be stopped as described in the Bundle.stop method.
3 Each bundle in the dependency closure that is in the RESOLVED state is
unresolved and thus moved to the INSTALLED state. The effect of this
step is that bundles in the dependency closure are no longer RESOLVED.
4 *Each bundle in the dependency closure that is in the UNINSTALLED
state is removed from the dependency closure and is now completely
removed from the Framework.*
5 Each bundle in the dependency closure that was in the ACTIVE state
prior to Step 2 is started as described in the Bundle.start method,
causing all bundles required for the restart to be resolved. It is
possible that, as a result of the previous steps, packages that were
previously exported no longer are. Therefore, some bundles may be
unresolvable until bundles satisfying the dependencies have been
installed in the Framework.
> On 21/02/12 12:32, Richard S. Hall wrote:
>> On 2/20/12 20:52 , San Martín, Matías wrote:
>>> Many thanks Richard for your reply, I didn't know this behavior of the
>>> framework.
>>
>> Well, there is some debate about it. I think Equinox does it
>> differently. The only safe thing to do is to completely refresh after
>> performing uninstalls and updates, not just selective refreshes.
>>
>> -> richard
>>
>>>
>>> El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
>>>> If you are not refreshing the bundle you uninstalled, then it
>>>> doesn't go away. You need to invoke the refresh command with no
>>>> args at the Gogo prompt. The framework won't auto refresh a bundle
>>>> unless there are no dependencies on it at the time it was uninstalled.
>>>>
>>>> The Felix framework will use all available bundles to resolve
>>>> dependencies, even ones that are pending removal.
>>>>
>>>> So, in short, use 'refresh' to really get rid of everything.
>>>>
>>>> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
>>>>
>>>>> Hi everybody,
>>>>> As the subject of this mail states, I'm facing a situation where a
>>>>> bundle stays wired to an uninstalled one even after refreshing the
>>>>> former.
>>>>> I checked that no other bundle stays wired to the uninstalled one.
>>>>> I'm using Apache Felix version 4.0.2.
>>>>> I'm new in the OSGi world so I'm not sure if that is an expected
>>>>> behavior.
>>>>>
>>>>> Here are the results of executing "lb" and "inspect requirement
>>>>> osgi.wiring.package" with my specific bundles (i.e. bundles that are
>>>>> developed by me for this test):
>>>>>
>>>>> =================================================================
>>>>> g! lb
>>>>> START LEVEL 1
>>>>> ID|State |Level|Name
>>>>> 0|Active | 0|System Bundle (4.0.2)
>>>>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
>>>>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
>>>>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
>>>>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
>>>>> 31|Active | 1|Apache Felix Http Api (2.2.0)
>>>>> 32|Active | 1|Apache Felix Http Base (2.2.0)
>>>>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
>>>>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
>>>>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
>>>>> 37|Active | 1|OSGi OBR Service API (1.0.0)
>>>>> 68|Resolved | 1|Console (1.0.0)
>>>>> 69|Resolved | 1|Inter (1.0.0)
>>>>> 70|Resolved | 1|Main (1.0.0)
>>>>> =====================================================================
>>>>>
>>>>> Here bundles 68, 69 and 70 are the ones I developed (note that bundle
>>>>> 71
>>>>> was the one that I uninstalled).
>>>>>
>>>>> =====================================================================
>>>>> g! inspect requirement osgi.wiring.package 68 69 70
>>>>> test.osgi.dynload.bundle.echoer.console [68] requires:
>>>>> ------------------------------------------------------
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0
>>>>> from
>>>>> test.osgi.dynload.bundle.inter [69]
>>>>>
>>>>> test.osgi.dynload.bundle.inter [69] requires:
>>>>> ---------------------------------------------
>>>>> osgi.wiring.package [EMPTY]
>>>>>
>>>>> test.osgi.dynload.bundle.main [70] requires:
>>>>> --------------------------------------------
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
>>>>> by:
>>>>> osgi.wiring.package; org.osgi.framework 1.6.0 from
>>>>> org.apache.felix.framework [0]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
>>>> >from test.osgi.dynload.bundle.echoer.console [68]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0
>>>>> from
>>>>> test.osgi.dynload.bundle.inter [69]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>>>>>
>>>>> resolved by:
>>>>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
>>>> >from test.osgi.dynload.bundle.runner.thread [71]
>>>>> =====================================================================
>>>>>
>>>>> That last line is the one I don't get. For what I know, after
>>>>> refreshing
>>>>> the bundle 70, the bundle 71 shouldn't be available anymore (then,
>>>>> the
>>>>> 70 shouldn't be able to resolve again).
>>>>>
>>>>> Has anybody have a clue about what's happening?
>>>>> Thank you in advance,
>>>>> Regards
>>>> --
>>>> Sent from my phone, excuse my brevity.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Refreshed bundle still wired to uninstalled one
Posted by Matias SM <ma...@yahoo.com.ar>.
Hi Richard,
I know I'm resurrecting a little old thread, but I'm reading the core
specification (Release 4, Version 4.3) and it says (section 7.3 "Wiring"):
/Refreshing happens on a per bundle basis but takes any Bundle
Wirings into account that depend on the refreshed bundle. In the
previous example, if bundle B is refreshed, it will automatically
refresh bundle A because A is wired to B. That is, bundle B is in
use by A./
So, if I understand correctly, the expected behavior for the test
presented at the beginning of this thread is that the bundle 70 should
change to the installed state after refreshing (bundle 71 should be
completely uninstalled). Am I missing something?
Kind regards
On 21/02/12 12:32, Richard S. Hall wrote:
> On 2/20/12 20:52 , San Martín, Matías wrote:
>> Many thanks Richard for your reply, I didn't know this behavior of the
>> framework.
>
> Well, there is some debate about it. I think Equinox does it
> differently. The only safe thing to do is to completely refresh after
> performing uninstalls and updates, not just selective refreshes.
>
> -> richard
>
>>
>> El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
>>> If you are not refreshing the bundle you uninstalled, then it
>>> doesn't go away. You need to invoke the refresh command with no args
>>> at the Gogo prompt. The framework won't auto refresh a bundle unless
>>> there are no dependencies on it at the time it was uninstalled.
>>>
>>> The Felix framework will use all available bundles to resolve
>>> dependencies, even ones that are pending removal.
>>>
>>> So, in short, use 'refresh' to really get rid of everything.
>>>
>>> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
>>>
>>>> Hi everybody,
>>>> As the subject of this mail states, I'm facing a situation where a
>>>> bundle stays wired to an uninstalled one even after refreshing the
>>>> former.
>>>> I checked that no other bundle stays wired to the uninstalled one.
>>>> I'm using Apache Felix version 4.0.2.
>>>> I'm new in the OSGi world so I'm not sure if that is an expected
>>>> behavior.
>>>>
>>>> Here are the results of executing "lb" and "inspect requirement
>>>> osgi.wiring.package" with my specific bundles (i.e. bundles that are
>>>> developed by me for this test):
>>>>
>>>> =================================================================
>>>> g! lb
>>>> START LEVEL 1
>>>> ID|State |Level|Name
>>>> 0|Active | 0|System Bundle (4.0.2)
>>>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
>>>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
>>>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
>>>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
>>>> 31|Active | 1|Apache Felix Http Api (2.2.0)
>>>> 32|Active | 1|Apache Felix Http Base (2.2.0)
>>>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
>>>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
>>>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
>>>> 37|Active | 1|OSGi OBR Service API (1.0.0)
>>>> 68|Resolved | 1|Console (1.0.0)
>>>> 69|Resolved | 1|Inter (1.0.0)
>>>> 70|Resolved | 1|Main (1.0.0)
>>>> =====================================================================
>>>>
>>>> Here bundles 68, 69 and 70 are the ones I developed (note that bundle
>>>> 71
>>>> was the one that I uninstalled).
>>>>
>>>> =====================================================================
>>>> g! inspect requirement osgi.wiring.package 68 69 70
>>>> test.osgi.dynload.bundle.echoer.console [68] requires:
>>>> ------------------------------------------------------
>>>> osgi.wiring.package;
>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>>>>
>>>> resolved by:
>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0
>>>> from
>>>> test.osgi.dynload.bundle.inter [69]
>>>>
>>>> test.osgi.dynload.bundle.inter [69] requires:
>>>> ---------------------------------------------
>>>> osgi.wiring.package [EMPTY]
>>>>
>>>> test.osgi.dynload.bundle.main [70] requires:
>>>> --------------------------------------------
>>>> osgi.wiring.package;
>>>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
>>>> by:
>>>> osgi.wiring.package; org.osgi.framework 1.6.0 from
>>>> org.apache.felix.framework [0]
>>>> osgi.wiring.package;
>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>>>>
>>>> resolved by:
>>>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
>>> >from test.osgi.dynload.bundle.echoer.console [68]
>>>> osgi.wiring.package;
>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>>>>
>>>> resolved by:
>>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0
>>>> from
>>>> test.osgi.dynload.bundle.inter [69]
>>>> osgi.wiring.package;
>>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>>>>
>>>> resolved by:
>>>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
>>> >from test.osgi.dynload.bundle.runner.thread [71]
>>>> =====================================================================
>>>>
>>>> That last line is the one I don't get. For what I know, after
>>>> refreshing
>>>> the bundle 70, the bundle 71 shouldn't be available anymore (then, the
>>>> 70 shouldn't be able to resolve again).
>>>>
>>>> Has anybody have a clue about what's happening?
>>>> Thank you in advance,
>>>> Regards
>>> --
>>> Sent from my phone, excuse my brevity.
>>
>>
>> ---------------------------------------------------------------------
>> 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: Refreshed bundle still wired to uninstalled one
Posted by San,
Matías <ma...@yahoo.com.ar>.
Yes, Equinox does it differently. When refreshed the bundle, it couldn't
resolve anymore.
El mar, 21-02-2012 a las 10:32 -0500, Richard S. Hall escribió:
> On 2/20/12 20:52 , San Martín, Matías wrote:
> > Many thanks Richard for your reply, I didn't know this behavior of the
> > framework.
>
> Well, there is some debate about it. I think Equinox does it
> differently. The only safe thing to do is to completely refresh after
> performing uninstalls and updates, not just selective refreshes.
>
> -> richard
>
> >
> > El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
> >> If you are not refreshing the bundle you uninstalled, then it doesn't go away. You need to invoke the refresh command with no args at the Gogo prompt. The framework won't auto refresh a bundle unless there are no dependencies on it at the time it was uninstalled.
> >>
> >> The Felix framework will use all available bundles to resolve dependencies, even ones that are pending removal.
> >>
> >> So, in short, use 'refresh' to really get rid of everything.
> >>
> >> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
> >>
> >>> Hi everybody,
> >>> As the subject of this mail states, I'm facing a situation where a
> >>> bundle stays wired to an uninstalled one even after refreshing the
> >>> former.
> >>> I checked that no other bundle stays wired to the uninstalled one.
> >>> I'm using Apache Felix version 4.0.2.
> >>> I'm new in the OSGi world so I'm not sure if that is an expected
> >>> behavior.
> >>>
> >>> Here are the results of executing "lb" and "inspect requirement
> >>> osgi.wiring.package" with my specific bundles (i.e. bundles that are
> >>> developed by me for this test):
> >>>
> >>> =================================================================
> >>> g! lb
> >>> START LEVEL 1
> >>> ID|State |Level|Name
> >>> 0|Active | 0|System Bundle (4.0.2)
> >>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
> >>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
> >>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
> >>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
> >>> 31|Active | 1|Apache Felix Http Api (2.2.0)
> >>> 32|Active | 1|Apache Felix Http Base (2.2.0)
> >>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
> >>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
> >>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
> >>> 37|Active | 1|OSGi OBR Service API (1.0.0)
> >>> 68|Resolved | 1|Console (1.0.0)
> >>> 69|Resolved | 1|Inter (1.0.0)
> >>> 70|Resolved | 1|Main (1.0.0)
> >>> =====================================================================
> >>>
> >>> Here bundles 68, 69 and 70 are the ones I developed (note that bundle
> >>> 71
> >>> was the one that I uninstalled).
> >>>
> >>> =====================================================================
> >>> g! inspect requirement osgi.wiring.package 68 69 70
> >>> test.osgi.dynload.bundle.echoer.console [68] requires:
> >>> ------------------------------------------------------
> >>> osgi.wiring.package;
> >>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
> >>> resolved by:
> >>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
> >>> test.osgi.dynload.bundle.inter [69]
> >>>
> >>> test.osgi.dynload.bundle.inter [69] requires:
> >>> ---------------------------------------------
> >>> osgi.wiring.package [EMPTY]
> >>>
> >>> test.osgi.dynload.bundle.main [70] requires:
> >>> --------------------------------------------
> >>> osgi.wiring.package;
> >>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
> >>> by:
> >>> osgi.wiring.package; org.osgi.framework 1.6.0 from
> >>> org.apache.felix.framework [0]
> >>> osgi.wiring.package;
> >>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
> >>> resolved by:
> >>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
> >> >from test.osgi.dynload.bundle.echoer.console [68]
> >>> osgi.wiring.package;
> >>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
> >>> resolved by:
> >>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
> >>> test.osgi.dynload.bundle.inter [69]
> >>> osgi.wiring.package;
> >>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
> >>> resolved by:
> >>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
> >> >from test.osgi.dynload.bundle.runner.thread [71]
> >>> =====================================================================
> >>>
> >>> That last line is the one I don't get. For what I know, after
> >>> refreshing
> >>> the bundle 70, the bundle 71 shouldn't be available anymore (then, the
> >>> 70 shouldn't be able to resolve again).
> >>>
> >>> Has anybody have a clue about what's happening?
> >>> Thank you in advance,
> >>> Regards
> >> --
> >> Sent from my phone, excuse my brevity.
> >
> >
> > ---------------------------------------------------------------------
> > 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: Refreshed bundle still wired to uninstalled one
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 2/20/12 20:52 , San Martín, Matías wrote:
> Many thanks Richard for your reply, I didn't know this behavior of the
> framework.
Well, there is some debate about it. I think Equinox does it
differently. The only safe thing to do is to completely refresh after
performing uninstalls and updates, not just selective refreshes.
-> richard
>
> El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
>> If you are not refreshing the bundle you uninstalled, then it doesn't go away. You need to invoke the refresh command with no args at the Gogo prompt. The framework won't auto refresh a bundle unless there are no dependencies on it at the time it was uninstalled.
>>
>> The Felix framework will use all available bundles to resolve dependencies, even ones that are pending removal.
>>
>> So, in short, use 'refresh' to really get rid of everything.
>>
>> "San Martín, Matías"<ma...@yahoo.com.ar> wrote:
>>
>>> Hi everybody,
>>> As the subject of this mail states, I'm facing a situation where a
>>> bundle stays wired to an uninstalled one even after refreshing the
>>> former.
>>> I checked that no other bundle stays wired to the uninstalled one.
>>> I'm using Apache Felix version 4.0.2.
>>> I'm new in the OSGi world so I'm not sure if that is an expected
>>> behavior.
>>>
>>> Here are the results of executing "lb" and "inspect requirement
>>> osgi.wiring.package" with my specific bundles (i.e. bundles that are
>>> developed by me for this test):
>>>
>>> =================================================================
>>> g! lb
>>> START LEVEL 1
>>> ID|State |Level|Name
>>> 0|Active | 0|System Bundle (4.0.2)
>>> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
>>> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
>>> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
>>> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
>>> 31|Active | 1|Apache Felix Http Api (2.2.0)
>>> 32|Active | 1|Apache Felix Http Base (2.2.0)
>>> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
>>> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
>>> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
>>> 37|Active | 1|OSGi OBR Service API (1.0.0)
>>> 68|Resolved | 1|Console (1.0.0)
>>> 69|Resolved | 1|Inter (1.0.0)
>>> 70|Resolved | 1|Main (1.0.0)
>>> =====================================================================
>>>
>>> Here bundles 68, 69 and 70 are the ones I developed (note that bundle
>>> 71
>>> was the one that I uninstalled).
>>>
>>> =====================================================================
>>> g! inspect requirement osgi.wiring.package 68 69 70
>>> test.osgi.dynload.bundle.echoer.console [68] requires:
>>> ------------------------------------------------------
>>> osgi.wiring.package;
>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>>> resolved by:
>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
>>> test.osgi.dynload.bundle.inter [69]
>>>
>>> test.osgi.dynload.bundle.inter [69] requires:
>>> ---------------------------------------------
>>> osgi.wiring.package [EMPTY]
>>>
>>> test.osgi.dynload.bundle.main [70] requires:
>>> --------------------------------------------
>>> osgi.wiring.package;
>>> (&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
>>> by:
>>> osgi.wiring.package; org.osgi.framework 1.6.0 from
>>> org.apache.felix.framework [0]
>>> osgi.wiring.package;
>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>>> resolved by:
>>> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
>> >from test.osgi.dynload.bundle.echoer.console [68]
>>> osgi.wiring.package;
>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>>> resolved by:
>>> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
>>> test.osgi.dynload.bundle.inter [69]
>>> osgi.wiring.package;
>>> (&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>>> resolved by:
>>> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
>> >from test.osgi.dynload.bundle.runner.thread [71]
>>> =====================================================================
>>>
>>> That last line is the one I don't get. For what I know, after
>>> refreshing
>>> the bundle 70, the bundle 71 shouldn't be available anymore (then, the
>>> 70 shouldn't be able to resolve again).
>>>
>>> Has anybody have a clue about what's happening?
>>> Thank you in advance,
>>> Regards
>> --
>> Sent from my phone, excuse my brevity.
>
>
> ---------------------------------------------------------------------
> 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: Refreshed bundle still wired to uninstalled one
Posted by San,
Matías <ma...@yahoo.com.ar>.
Many thanks Richard for your reply, I didn't know this behavior of the
framework.
El lun, 20-02-2012 a las 20:24 -0500, Richard S. Hall escribió:
> If you are not refreshing the bundle you uninstalled, then it doesn't go away. You need to invoke the refresh command with no args at the Gogo prompt. The framework won't auto refresh a bundle unless there are no dependencies on it at the time it was uninstalled.
>
> The Felix framework will use all available bundles to resolve dependencies, even ones that are pending removal.
>
> So, in short, use 'refresh' to really get rid of everything.
>
> "San Martín, Matías" <ma...@yahoo.com.ar> wrote:
>
> >Hi everybody,
> >As the subject of this mail states, I'm facing a situation where a
> >bundle stays wired to an uninstalled one even after refreshing the
> >former.
> >I checked that no other bundle stays wired to the uninstalled one.
> >I'm using Apache Felix version 4.0.2.
> >I'm new in the OSGi world so I'm not sure if that is an expected
> >behavior.
> >
> >Here are the results of executing "lb" and "inspect requirement
> >osgi.wiring.package" with my specific bundles (i.e. bundles that are
> >developed by me for this test):
> >
> >=================================================================
> >g! lb
> >START LEVEL 1
> >ID|State |Level|Name
> > 0|Active | 0|System Bundle (4.0.2)
> > 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
> > 2|Active | 1|Apache Felix Gogo Command (0.12.0)
> > 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
> > 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
> > 31|Active | 1|Apache Felix Http Api (2.2.0)
> > 32|Active | 1|Apache Felix Http Base (2.2.0)
> > 33|Active | 1|Apache Felix Http Bundle (2.2.0)
> > 34|Active | 1|Apache Felix Http Jetty (2.2.0)
> > 35|Active | 1|Apache Felix Web Management Console (3.1.8)
> > 37|Active | 1|OSGi OBR Service API (1.0.0)
> > 68|Resolved | 1|Console (1.0.0)
> > 69|Resolved | 1|Inter (1.0.0)
> > 70|Resolved | 1|Main (1.0.0)
> >=====================================================================
> >
> >Here bundles 68, 69 and 70 are the ones I developed (note that bundle
> >71
> >was the one that I uninstalled).
> >
> >=====================================================================
> >g! inspect requirement osgi.wiring.package 68 69 70
> >test.osgi.dynload.bundle.echoer.console [68] requires:
> >------------------------------------------------------
> >osgi.wiring.package;
> >(&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
> >resolved by:
> > osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
> >test.osgi.dynload.bundle.inter [69]
> >
> >test.osgi.dynload.bundle.inter [69] requires:
> >---------------------------------------------
> >osgi.wiring.package [EMPTY]
> >
> >test.osgi.dynload.bundle.main [70] requires:
> >--------------------------------------------
> >osgi.wiring.package;
> >(&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
> >by:
> > osgi.wiring.package; org.osgi.framework 1.6.0 from
> >org.apache.felix.framework [0]
> >osgi.wiring.package;
> >(&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
> >resolved by:
> > osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
> >from test.osgi.dynload.bundle.echoer.console [68]
> >osgi.wiring.package;
> >(&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
> >resolved by:
> > osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
> >test.osgi.dynload.bundle.inter [69]
> >osgi.wiring.package;
> >(&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
> >resolved by:
> > osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
> >from test.osgi.dynload.bundle.runner.thread [71]
> >=====================================================================
> >
> >That last line is the one I don't get. For what I know, after
> >refreshing
> >the bundle 70, the bundle 71 shouldn't be available anymore (then, the
> >70 shouldn't be able to resolve again).
> >
> >Has anybody have a clue about what's happening?
> >Thank you in advance,
> >Regards
>
> --
> Sent from my phone, excuse my brevity.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Refreshed bundle still wired to uninstalled one
Posted by "Richard S. Hall" <he...@ungoverned.org>.
If you are not refreshing the bundle you uninstalled, then it doesn't go away. You need to invoke the refresh command with no args at the Gogo prompt. The framework won't auto refresh a bundle unless there are no dependencies on it at the time it was uninstalled.
The Felix framework will use all available bundles to resolve dependencies, even ones that are pending removal.
So, in short, use 'refresh' to really get rid of everything.
"San Martín, Matías" <ma...@yahoo.com.ar> wrote:
>Hi everybody,
>As the subject of this mail states, I'm facing a situation where a
>bundle stays wired to an uninstalled one even after refreshing the
>former.
>I checked that no other bundle stays wired to the uninstalled one.
>I'm using Apache Felix version 4.0.2.
>I'm new in the OSGi world so I'm not sure if that is an expected
>behavior.
>
>Here are the results of executing "lb" and "inspect requirement
>osgi.wiring.package" with my specific bundles (i.e. bundles that are
>developed by me for this test):
>
>=================================================================
>g! lb
>START LEVEL 1
>ID|State |Level|Name
> 0|Active | 0|System Bundle (4.0.2)
> 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
> 2|Active | 1|Apache Felix Gogo Command (0.12.0)
> 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
> 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
> 31|Active | 1|Apache Felix Http Api (2.2.0)
> 32|Active | 1|Apache Felix Http Base (2.2.0)
> 33|Active | 1|Apache Felix Http Bundle (2.2.0)
> 34|Active | 1|Apache Felix Http Jetty (2.2.0)
> 35|Active | 1|Apache Felix Web Management Console (3.1.8)
> 37|Active | 1|OSGi OBR Service API (1.0.0)
> 68|Resolved | 1|Console (1.0.0)
> 69|Resolved | 1|Inter (1.0.0)
> 70|Resolved | 1|Main (1.0.0)
>=====================================================================
>
>Here bundles 68, 69 and 70 are the ones I developed (note that bundle
>71
>was the one that I uninstalled).
>
>=====================================================================
>g! inspect requirement osgi.wiring.package 68 69 70
>test.osgi.dynload.bundle.echoer.console [68] requires:
>------------------------------------------------------
>osgi.wiring.package;
>(&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0)(!(version>=2.0.0)))
>resolved by:
> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
>test.osgi.dynload.bundle.inter [69]
>
>test.osgi.dynload.bundle.inter [69] requires:
>---------------------------------------------
>osgi.wiring.package [EMPTY]
>
>test.osgi.dynload.bundle.main [70] requires:
>--------------------------------------------
>osgi.wiring.package;
>(&(osgi.wiring.package=org.osgi.framework)(version>=1.3.0)) resolved
>by:
> osgi.wiring.package; org.osgi.framework 1.6.0 from
>org.apache.felix.framework [0]
>osgi.wiring.package;
>(&(osgi.wiring.package=test.osgi.dynload.bundle.echoer.console)(version>=1.0.0)(!(version>=2.0.0)))
>resolved by:
> osgi.wiring.package; test.osgi.dynload.bundle.echoer.console 1.0.0
>from test.osgi.dynload.bundle.echoer.console [68]
>osgi.wiring.package;
>(&(osgi.wiring.package=test.osgi.dynload.bundle.inter.echoer)(version>=1.0.0))
>resolved by:
> osgi.wiring.package; test.osgi.dynload.bundle.inter.echoer 1.0.0 from
>test.osgi.dynload.bundle.inter [69]
>osgi.wiring.package;
>(&(osgi.wiring.package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>resolved by:
> osgi.wiring.package; test.osgi.dynload.bundle.runner.thread 1.0.0
>from test.osgi.dynload.bundle.runner.thread [71]
>=====================================================================
>
>That last line is the one I don't get. For what I know, after
>refreshing
>the bundle 70, the bundle 71 shouldn't be available anymore (then, the
>70 shouldn't be able to resolve again).
>
>Has anybody have a clue about what's happening?
>Thank you in advance,
>Regards
--
Sent from my phone, excuse my brevity.