felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Refreshed bundle still wired to uninstalled one
Date Fri, 06 Apr 2012 20:22:33 GMT
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"<matias_sm@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


Mime
View raw message