Re: OBR RepositoryAdmin content in embeded framework
On 29/05/12 23:50, Richard S. Hall wrote: On 5/29/12 20:46 , Matias SM wrote: On 29/05/12 20:42, Richard S. Hall wrote: On 5/29/12 18:31 , Matias SM wrote: On 29/05/12 13:58, Richard S. Hall wrote: On 5/29/12 12:49 , matias san martin wrote: De: Richard S. Hallhe...@ungoverned.org Para: users@felix.apache.org Enviado: martes, 29 de mayo de 2012 0:02 Asunto: Re: OBR RepositoryAdmin content in embeded framework On 5/28/12 21:03 , Matias SM wrote: Hi again Richard, I've been investigating further and I realized my confusion came because it seems that, while OBR takes into account the installed by hand bundles to resolve as requested, it doesn't respond about those resources (associated to the bundles installed by hand). That is, if I try to resolve() a bundle by using the RepositoryAdmin, it knows about the installed by hand bundles. But, if I try to getResources() or discoverResources(..), I get no results. Is there a way of getting the installed by hand resources from the RepositoryAdmin without creating a repository? Off the top of my head, I don't know. I would assume that the RepositoryAdmin is only querying actual repositories for discoverResources() et al, so you won't get back resources from the fake local repository. Not sure what is the correct thing here, but I'm inclined to think the current behavior makes sense, since technically installed bundles do *not* form a repository (e.g., it is not possible to download them). Thank you for the clarifications Richard, I understand your point and I agree with you. However, I may be wrong but, bundles (I think) are always installed from a source, so it may be possible to use that as the URI of the resource. Yes, they are always installed from a source, but that information isn't saved when installing via OBR, nor can the bundle include its source in its manifest, since it may come from a number of sources. I understand. Also, I think it would be a nice improvement to have some logic capable of fetching this information (maybe intercepting the installation command or something) and creating a full fledged repository with it. Yes, the would be the approach. The current OBR impl is too simplistic to do that, but a beefed up implementation could do something like that. Related to this, now that you mention it, I think that when creating a repository from bundles (by using the API), the resulting xml doesn't have a an URI attribute for the resources. Wouldn't that be wrong, taking into account that the resources should be downloable? Not sure. I've only created repositories using bindex and via the maven-bundle-plugin and both give a URI attribute. The case I mention could be reproduced by creating resources from bundles (DataModelHelper#createResource(Bundle)) and then a repository from those resources (DataModelHelper#repository(Resource[])). I think it is related to what you said about OBR being unable to get an URI from the Bundle. Yes, I'd imagine if it is starting from a Bundle, then there isn't much it can do about creating a URI. Should I create a JIRA issue to check this case? I guess the important question is, what would you like to have it do? There are valid use cases for modeling bundles as resources in a repository as OBR does for deploying against installed bundles, so we can't disallow it. Do you have some other suggestion? Maybe throwing an exception when calling writeRepository(..) with resources that doesn't have URI (i.e. avoid invalid persistent repositories, but allow an abstraction similar like that for in-memory use). I know this is not a great solution but at least would avoid (misleading) successful creation of invalid repositories. I don't have a strong opinion on this, but feel free to open a JIRA issue to see if anyone else has an opinion. It took me some time but finally created the JIRA issue https://issues.apache.org/jira/browse/FELIX-3541 Hope it will create an interesting discussion about the usefulness of my recommendation. Kind regards - richard - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR RepositoryAdmin content in embeded framework
On 29/05/12 20:42, Richard S. Hall wrote: On 5/29/12 18:31 , Matias SM wrote: On 29/05/12 13:58, Richard S. Hall wrote: On 5/29/12 12:49 , matias san martin wrote: De: Richard S. Hallhe...@ungoverned.org Para: users@felix.apache.org Enviado: martes, 29 de mayo de 2012 0:02 Asunto: Re: OBR RepositoryAdmin content in embeded framework On 5/28/12 21:03 , Matias SM wrote: Hi again Richard, I've been investigating further and I realized my confusion came because it seems that, while OBR takes into account the installed by hand bundles to resolve as requested, it doesn't respond about those resources (associated to the bundles installed by hand). That is, if I try to resolve() a bundle by using the RepositoryAdmin, it knows about the installed by hand bundles. But, if I try to getResources() or discoverResources(..), I get no results. Is there a way of getting the installed by hand resources from the RepositoryAdmin without creating a repository? Off the top of my head, I don't know. I would assume that the RepositoryAdmin is only querying actual repositories for discoverResources() et al, so you won't get back resources from the fake local repository. Not sure what is the correct thing here, but I'm inclined to think the current behavior makes sense, since technically installed bundles do *not* form a repository (e.g., it is not possible to download them). Thank you for the clarifications Richard, I understand your point and I agree with you. However, I may be wrong but, bundles (I think) are always installed from a source, so it may be possible to use that as the URI of the resource. Yes, they are always installed from a source, but that information isn't saved when installing via OBR, nor can the bundle include its source in its manifest, since it may come from a number of sources. I understand. Also, I think it would be a nice improvement to have some logic capable of fetching this information (maybe intercepting the installation command or something) and creating a full fledged repository with it. Yes, the would be the approach. The current OBR impl is too simplistic to do that, but a beefed up implementation could do something like that. Related to this, now that you mention it, I think that when creating a repository from bundles (by using the API), the resulting xml doesn't have a an URI attribute for the resources. Wouldn't that be wrong, taking into account that the resources should be downloable? Not sure. I've only created repositories using bindex and via the maven-bundle-plugin and both give a URI attribute. The case I mention could be reproduced by creating resources from bundles (DataModelHelper#createResource(Bundle)) and then a repository from those resources (DataModelHelper#repository(Resource[])). I think it is related to what you said about OBR being unable to get an URI from the Bundle. Yes, I'd imagine if it is starting from a Bundle, then there isn't much it can do about creating a URI. Should I create a JIRA issue to check this case? I guess the important question is, what would you like to have it do? There are valid use cases for modeling bundles as resources in a repository as OBR does for deploying against installed bundles, so we can't disallow it. Do you have some other suggestion? Maybe throwing an exception when calling writeRepository(..) with resources that doesn't have URI (i.e. avoid invalid persistent repositories, but allow an abstraction similar like that for in-memory use). I know this is not a great solution but at least would avoid (misleading) successful creation of invalid repositories. Kind regards - richard Kind regards and thank you for your comments - richard Kind regards - richard Thank you in advance for your help Kind regards - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
OBR RepositoryAdmin content in embeded framework
Hi everybody, I'm wondering about a difference in the behavior of OBR when using a Felix framework from gogo with respect to an embedded one. Using gogo, if I install and start a bundle through the command line (gogo), If another bundle queries the (OBR) repositoryAdmin, it would be able to see the first bundle (the one installed by hand). However, doing some testing with an embedded framework, if I install (and start) a bundle directly in the framework, then another started bundle is not being able to see the first one. The questions: - Is this an expected behavior? - What should I do to be able to see the installed by hand bundle in the 2nd use case (the one with an embedded framewor)? The only way is by creating a repository and adding it to the repositoryAdmin? - What does gogo do that lets the first use case work? Thank you in advance for any comment about this. Kind regards
getting bundle's closure by using FrameworkWiring.getDependencyClosure
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
Re: getting bundle's closure by using FrameworkWiring.getDependencyClosure
Thanks for your fast comment Richard! And, yes I am sure it is resolved. In fact, executing in gogo inspect requirement osgi.wiring.package myBundle's id lists the bundles I expected the method call would return. I have a bundle myBundle that requires a few others, then my test steps are: From gogo: deploy and start (using OBR) myBundle(it and its dependencies get active) stop myBundle(it goes to state resolved) install my test bundle (testBundle) that executes the code from my original mail start testBundle And it prints the collection returned by getDependencyClosure that only contains myBundle. I would be happy to give you any other information you need to help me understand what is going wrong. Kind regards On 10/05/12 20:25, Richard S. Hall wrote: Should work. Are you sure your bundle is resolved? - 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-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: getting bundle's closure by using FrameworkWiring.getDependencyClosure
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-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Refreshed bundle still wired to uninstalled one
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íasmatias...@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
Re: Refreshed bundle still wired to uninstalled one
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íasmatias...@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
Re: Refreshed bundle still wired to uninstalled one
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íasmatias...@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
Re: Refreshed bundle still wired to uninstalled one
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-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR and automatic bundle update
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 SMmatias...@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
Re: OBR and automatic bundle update
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
Re: OBR and automatic bundle update
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
Re: OBR and automatic bundle update
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 SMmatias...@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-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: OBR and automatic bundle update
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
Re: Blocked Thread while shutting down Felix / IPojo
I don't know if that may be your issue but in the book OSGi in action [1] they recommend that if a bundle want to stop itself, it should do so in a different thread. This is to avoid possible deadlocks if as part of the bundle finalization there is any waiting for the calls to finish. You can refer to the book's source code examples [2]. HTH, Regards [1] http://www.manning.com/hall/ [2] http://code.google.com/p/osgi-in-action/source/browse/trunk/chapter03/shell-example/org.foo.shell/src/org/foo/shell/StopCommand.java On 02/04/12 14:46, Gay David (Annecy) wrote: Hi, I'm currently have a problem with Felix and or IPojo. Basically the problem is when Felix is starting up and services are still registering while and in the meantime a stop Felix is request. The code to stop is simple : getBundle(0).stop(); If I have a look at the thread dump on JVisualVM, I have (full thread dump in attachement) : FelixStartLevel daemon prio=6 tid=0x06d6c000 nid=0xb00 waiting for monitor entry [0x07fbf000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.felix.ipojo.IPojoFactory.removeFactoryStateListener(IPojoFactory.java:491) - waiting to lock 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.InstanceCreator.removeFactory(InstanceCreator.java:187) at org.apache.felix.ipojo.Extender.closeManagementFor(Extender.java:156) at org.apache.felix.ipojo.Extender.bundleChanged(Extender.java:129) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4245) at org.apache.felix.framework.Felix.stopBundle(Felix.java:2352) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1215) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295) at java.lang.Thread.run(Unknown Source) Locked ownable synchronizers: - None And Thread-2 daemon prio=6 tid=0x07050800 nid=0x6d8 in Object.wait() [0x084bd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xc029d238 (a [Ljava.lang.Object;) at java.lang.Object.wait(Object.java:485) at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4872) - locked 0xc029d238 (a [Ljava.lang.Object;) at org.apache.felix.framework.Felix.registerService(Felix.java:3206) at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) at org.apache.felix.ipojo.IPojoContext.registerService(IPojoContext.java:338) at org.apache.felix.ipojo.handlers.providedservice.ProvidedService.registerService(ProvidedService.java:345) - locked 0xeafc8ea0 (a org.apache.felix.ipojo.handlers.providedservice.ProvidedService) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.__stateChanged(ProvidedServiceHandler.java:494) at org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler.stateChanged(ProvidedServiceHandler.java) at org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:471) at org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:353) at org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:166) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:301) - locked 0xc048c790 (a org.apache.felix.ipojo.ComponentFactory) at org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:238) at org.apache.felix.ipojo.Factory$$Proxy.createComponentInstance(Unknown Source) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__createAndStart(ComponentDefinition.java:147) at com.axway.cmp.ume.ui.internal.ComponentDefinition.createAndStart(ComponentDefinition.java) at com.axway.cmp.ume.ui.internal.ComponentDefinition.__validate(ComponentDefinition.java:85) at com.axway.cmp.ume.ui.internal.ComponentDefinition.validate(ComponentDefinition.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: OBR and automatic bundle update
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
Re: OBR and automatic bundle update
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
Re: OBR and automatic bundle update
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-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
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-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Look for a missing dependency in OBR
Thank you very much for your help Richard. I will start another thread about my distribution problem to set a context and hopefully get some insights about other possible approaches to the problem. Regards and thanks again. On 18/03/12 00:13, Richard S. Hall wrote: On 3/17/12 20:59 , Matias SM wrote: Thank you for your answer Richard. Is that API available as a bundle to download? The Felix OBR bundle provides that API. The OSGi API is also optionally provided, but you have to download that OSGi OBR API as a separate bundle. (i.e., you only need the Felix OBR bundle installed to use the Felix OBR API, but you need the Felix OBR bundle and the OSGi OBR API bundle installed to use the OSGi OBR API with the Felix OBR implementation) I see in the Felix svn trunk that the RepositoryAdmin has a new method: Resource[] discoverResources(Requirement[] requirements); Is that what you mean? Yes. Also, I need to ask for the resource (bundle) in other server, so I need to transmit the requirement through the network. Is there a way to do this (e.g. create a requirement from a string) using only the exported API or should I use the specific implementation? Not sure what you mean. The OBR bundle and/or spec has nothing to do with distribution, so you are on your own there. However, yes, it should be fairly easy to serialize a requirement since they are already read from an XML file to begin with. - richard On 17/03/12 20:50, Richard S. Hall wrote: The original proposed OSGi OBR API didn't provide a way to do this from the RepositoryAdmin. You need to use the Felix OBR API, which exposes such functionality on its RepositoryAdmin. - richard On 3/17/12 19:16 , San Martín, Matías wrote: Hi everybody, I'm doing some experimentation with OBR (API) and I don't know how to find a missing requirement with it. That is, if I have a filter expression (as used in a resource's require description in a repository xml file), is there a way to query the OBR service (by means of the repositoryAdmin, I guess) for the bundles that satisfy that requirement? For example, I have the filter: ((package=org.foo.somepackage)(version=1.3.0)) Then I would like to query for some bundle that exports the package org.foo.somepackage with a version = 1.3.0. From the documentation in the RepositoryAdmin class (revision 1.3): Checking the capabilities of the filters is not possible because that requires a new construct in the filter. I guess it can't be done. But maybe I'm missing something. Thanks in advance for any insight about this. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Fetching bundles from different OBR services
Hi everybody, I'm trying to implement some logic that allows a network node to fetch some bundles from other and install them into its own OBR service. I will try to explain the problem better. Lets say I have two network nodes (i.e. servers in some place of a network), each one has an OBR service running. Then, what I try to do is the following: - node N1 sends a bundle B to node N2 (in N1, B is correctly resolved) - N2 tries to deploy B but it may have some missing dependencies - N2 needs to satisfy B's missing dependencies so it may ask N1 for them. At the end of the day , what I try to do is to be able to start B in N2. The way this is achieved is what I would like to get some insights about. Since N2 can receive bundles from different (and possibly several) nodes, it's not feasible that the nodes synchronizes their repositories so each one can know which bundles are missing and ask for them directly. A valid approach is that N1 send a repository file containing all the information about the bundles to which B is wired. However this approach could mean unnecessary network traffic if N2 has already all the needed dependencies for B. Since I'm really new with OSGi, Felix and OBR, I would like to ask you for some insights about this or better solutions to get the job done. Hope I stated the problem clearly enough Thank you for your help
Re: Look for a missing dependency in OBR
Thank you for your answer Richard. Is that API available as a bundle to download? I see in the Felix svn trunk that the RepositoryAdmin has a new method: Resource[] discoverResources(Requirement[] requirements); Is that what you mean? Also, I need to ask for the resource (bundle) in other server, so I need to transmit the requirement through the network. Is there a way to do this (e.g. create a requirement from a string) using only the exported API or should I use the specific implementation? On 17/03/12 20:50, Richard S. Hall wrote: The original proposed OSGi OBR API didn't provide a way to do this from the RepositoryAdmin. You need to use the Felix OBR API, which exposes such functionality on its RepositoryAdmin. - richard On 3/17/12 19:16 , San Martín, Matías wrote: Hi everybody, I'm doing some experimentation with OBR (API) and I don't know how to find a missing requirement with it. That is, if I have a filter expression (as used in a resource's require description in a repository xml file), is there a way to query the OBR service (by means of the repositoryAdmin, I guess) for the bundles that satisfy that requirement? For example, I have the filter: ((package=org.foo.somepackage)(version=1.3.0)) Then I would like to query for some bundle that exports the package org.foo.somepackage with a version = 1.3.0. From the documentation in the RepositoryAdmin class (revision 1.3): Checking the capabilities of the filters is not possible because that requires a new construct in the filter. I guess it can't be done. But maybe I'm missing something. Thanks in advance for any insight about this. - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
