felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From matias san martin <matias...@yahoo.com.ar>
Subject Re: getting bundle's closure by using FrameworkWiring.getDependencyClosure
Date Fri, 11 May 2012 19:26:03 GMT
Hi Richard, thank you again for your help. 
I understand what you are saying about the closure being "invalid" if somebody refreshes the
bundle as soon as the closure is calculated. However that is not much of an issue for my use
case, but the fact of having an invalid snapshot (because a refresh was done in the middle
of the processing) is.
I will follow your advice and register for refresh events to identify this case.

Thank you very much for your insights Richard
Kind regards



----- Mensaje original -----
> De: Richard S. Hall <heavy@ungoverned.org>
> Para: users@felix.apache.org
> CC: 
> Enviado: viernes, 11 de mayo de 2012 15:55
> Asunto: Re: getting bundle's closure by using FrameworkWiring.getDependencyClosure
> 
> On 5/11/12 12:46 , matias san martin wrote:
>>  Thank you for your answer and recommendation,Richard.
>> 
>>  Just to be sure, when "navigating" the requirements "by 
> hand" (with the logic you recommend), is possible that some bundles 
> disappear (get uninstalled) while processing, isn't it? If so, is there any 
> recommended way of reacting to this case? I would like to be sure that I get a 
> valid snapshot of the closure (even if the bundles are not the current 
> revision).
> 
> Yeah, you probably do have to worry about it. You effectively would need 
> to listen for the bundle you are calculating dependencies for to be 
> refreshed. If it gets refreshed while calculating, then your result is 
> invalid and you need to start again.
> 
> Of course, this is all pretty silly anyway, because if you have a high 
> level of churn, the result can be invalid as soon as you finish 
> calculating. This is true even when using the getDependencyClosure() 
> method. We are really just talking about consistent snapshot, not 
> something that is valid for any length of time.
> 
> -> richard
> 
>>  Thank you again for your insightsKind regards
>> 
>>>  ________________________________
>>>  De: Richard S. Hall<heavy@ungoverned.org>
>>>  Para: users@felix.apache.org
>>>  Enviado: jueves, 10 de mayo de 2012 23:26
>>>  Asunto: Re: getting bundle's closure by using 
> FrameworkWiring.getDependencyClosure
>>> 
>>>  Right. This only tells you which bundles depend on the target bundle, 
> not on which bundles it depends.
>>> 
>>>  This mechanism is intended to answer the question: "If I refresh 
> the target bundle, which other bundles will be impacted?"
>>> 
>>>  If no one depends on your bundle, then no on will be impacted.
>>> 
>>>  If you want to calculate it the other way around, it shouldn't be 
> too difficult. Just get your BundleWiring and walk all of your required wires to 
> their providers, then do this recursively for them.
>>> 
>>>  ->  richard
>>> 
>>>  On 5/10/12 19:47 , Matias SM wrote:
>>>>  Looking to this example and trying it in my case I think I 
> understand what is going wrong.
>>>>  If I run the commands you show, I get:
>>>>  g! ((bundle 0) adapt ((bundle 0) loadClass 
> org.osgi.framework.wiring.FrameworkWiring)) getDependencyClosure [ (bundle 9) ]
>>>>        9|Resolved   |    1|mybundle_symboicname (1.0.0)
>>>> 
>>>>  g! inspect c *package 9
>>>>  mybundle_symboicname[9] provides:
>>>>  -------------------------------------------
>>>>  *package [EMPTY]
>>>> 
>>>>  If I understand correctly this output, It is what I'd have 
> expected since myBundle doesn't have any capability.
>>>>  The thing is that I would expect that the Dependency Closure would 
> also contain the bundles related to myBundle's requirements. I think I may 
> misunderstood the documentation:
>>>>  ...The graph is expanded by adding any bundle that is either wired 
> to a package that is currently exported by a bundle in the graph or __requires a 
> bundle in the graph__...
>>>> 
>>>>   From that last part I thought that the bundles wired to myBundle 
> by its requirements would also be in the dependency closure.
>>>>  If that is not the case, is there a way to get the bundles wired to 
> myBundle by its requirements (and the requirements of those bundles, and so 
> on...)?
>>>> 
>>>>  Thank you again for your help
>>>>  Kind regards
>>>> 
>>>>  On 10/05/12 20:32, Richard S. Hall wrote:
>>>>>  Just as a follow up, I see something like this:
>>>>> 
>>>>>  g! lb
>>>>>  START LEVEL 1
>>>>>       ID|State      |Level|Name
>>>>>        0|Active     |    0|System Bundle (4.1.0.SNAPSHOT)
>>>>>        1|Active     |    1|uninstaller (0.0.0)
>>>>>        3|Active     |    1|Apache Felix Gogo Command (0.12.0)
>>>>>        4|Active     |    1|Apache Felix Gogo Runtime (0.10.0)
>>>>>        5|Active     |    1|Apache Felix Gogo Shell (0.10.0)
>>>>>  g! ((bundle 0) adapt ((bundle 0) loadClass 
> org.osgi.framework.wiring.FrameworkWiring)) getDependencyClosure [ (bundle 4) ]
>>>>>        5|Active     |    1|org.apache.felix.gogo.shell (0.10.0)
>>>>>        4|Active     |    1|org.apache.felix.gogo.runtime 
> (0.10.0)
>>>>>        3|Active     |    1|org.apache.felix.gogo.command 
> (0.12.0)
>>>>> 
>>>>>  g! inspect c *package 4
>>>>>  org.apache.felix.gogo.runtime [4] provides:
>>>>>  -------------------------------------------
>>>>>  osgi.wiring.package; org.apache.felix.service.command 0.10.0 
> required by:
>>>>>       org.apache.felix.gogo.shell [5]
>>>>>       org.apache.felix.gogo.command [3]
>>>>>  osgi.wiring.package; org.apache.felix.gogo.api 0.10.0 [UNUSED]
>>>>>  osgi.wiring.package; org.apache.felix.service.threadio 0.10.0 
> [UNUSED]
>>>>>  g!
>>>>> 
>>>>>  This looks correct, but there could always be bugs, I guess.
>>>>> 
>>>>>  ->  richard
>>>>> 
>>>>>  On 5/10/12 19:19 , Matias SM wrote:
>>>>>>  Hi everybody,
>>>>>>  I'm trying to get a bundle's dependency closure by 
> using the method getDependencyClosure. However if I do sth like:
>>>>>> 
> context.getBundle(0).adapt(FrameworkWiring.class).getDependencyClosure(Arrays.asList(myBundle));
>>>>>>  to get myBundle's closure, all this call is returning 
> is the bundle (myBundle) itself.
>>>>>> 
>>>>>>   From getDependencyClosure javadoc:
>>>>>>  /Returns the dependency closure for the specified bundles.
>>>>>>  A graph of bundles is computed starting with the specified 
> bundles. The graph is expanded by adding any bundle that is either wired to a 
> package that is currently exported by a bundle in the graph or requires a bundle 
> in the graph. The graph is fully constructed when there is no bundle outside the 
> graph that is wired to a bundle in the graph. The graph may contain UNINSTALLED 
> bundles that are removal pending./
>>>>>> 
>>>>>>  I understand that the result of the previously cited call 
> should be all the bundles wired (by a requirement or a capability) to myBundle.
>>>>>>  What am I doing wrong?
>>>>>> 
>>>>>>  And I would like to ask you also if there is a way of 
> getting only the closure formed by the bundles wired to myBundle by its 
> requirements (i.e. only get those bundles that are needed to resolve myBundle).
>>>>>> 
>>>>>>  Thanks in advance for any help you can kindly give me
>>>>>>  Kind regards
>>>>>> 
>>>>> 
> ---------------------------------------------------------------------
>>>>>  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


Mime
View raw message