felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matias SM <matias...@yahoo.com.ar>
Subject Re: Refreshed bundle still wired to uninstalled one
Date Fri, 06 Apr 2012 19:25:04 GMT


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message