You are right, uninstall() is called in the scope of start(). I will try it with a thread. Thank you all for your help!
cheers, Manuel > I agree, your bundle should register a bundle listener and wait until > it receives a bundle started event for its own bundle. Furthermore, > you need to make sure the framework has already started via a > combination out of framework listener and checking the system bundle. > Then you can start a new thread that does nothing else then > uninstalling the bundle. > > regards, > > Karl > > On Thu, Apr 16, 2009 at 2:44 PM, Rob Walker <r...@ascert.com> wrote: >> I could be wrong - but I don't recall anything in the OSGi spec >> explicitly >> forbidding this tbh. As for the deadlock, it's possible this may happen >> but >> my gut feel from working around that area of Felix code is it probably >> won't, especially as you note, a separate thread were used. >> >> As per my previous email - I think the more likely case here is that >> uninstall is being called while still in the scope of the start() >> method. >> That almost certainly needs to complete, hence the bundle needs to >> trigger >> an uninstall once start() has exited e.g. via a new thread. >> >> - Rob >> >> >> Christopher Armstrong wrote: >>> >>> Hi Manuel >>> >>> From what I know about the framework and from your stack trace below, I >>> would suggest that it is theoretically impossible for a bundle to >>> uninstall >>> itself. If a bundle were to issue a command to uninstall itself whilst >>> it is >>> starting up, you have a chicken and egg scenario. This would arise >>> because >>> the uninstall command would have to wait for the bundle to shutdown, at >>> the >>> same time the bundle is waiting for the uninstall command to finish. >>> >>> Maybe you could launch a separate thread that waits for the bundle to >>> shutdown or startup (or otherwise get into a consistent state), and >>> then >>> sets off the uninstall before quiting the thread. However, this could >>> still >>> rely on the indeterminate behaviour you demonstrated between Felix >>> versions. >>> It's also not clear how the framework interacts with uninstalled >>> bundles and >>> the garbage collector (would the thread crash because its class files >>> have >>> been forcibly removed?). >>> >>> The more correct solution would be to simply leave the management agent >>> bundle you've created in place, and leave it up to an administrator to >>> get >>> rid of. If you uninstalled it automatically, the running framework >>> would be >>> next to useless as it would required manual intervention to start >>> running >>> anything again. >>> >>> Cheers >>> Chris >>> >>> On 16/04/2009, at 10:25 PM, mir wrote: >>> >>>> Hello, >>>> >>>> We made a bundle (org.trialox.platform.launchbundle.jar) that installs >>>> others bundles and after that ituninstalls itself. >>>> >>>> In felix 1.0.4 it stated something like "uninstalling a bundle that is >>>> starting or stopping is currently not supported". In felix 1.4.1 it >>>> worked without warning. >>>> >>>> In felix 1.6.0 we get the exceptions below. I'm wondering what the >>>> correct way to do such a bundle that removes itself is. >>>> >>>> regards, >>>> Manuel >>>> >>>> >>>> [FelixDispatchQueue] DEBUG org.trialox.platform.launchbundle - >>>> FrameworkEvent ERROR >>>> org.osgi.framework.BundleException: Bundle >>>> org.trialox.platform.launchbundle [17] cannot be uninstalled, since it >>>> is either starting or stopping. >>>> at >>>> org.apache.felix.framework.Felix.uninstallBundle(Felix.java:1901) >>>> at >>>> org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:823) >>>> at org.trialox.platform.launchbundle.Main.start(Main.java:101) >>>> at >>>> >>>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) >>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1458) >>>> at >>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984) >>>> at >>>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263) >>>> at java.lang.Thread.run(Thread.java:619) >>>> ERROR: Error starting >>>> >>>> file:///home/mir/workspace/org.trialox.platform.launchbundle/target/org.trialox.platform.launchbundle.jar >>>> (org.osgi.framework.BundleException: Bundle >>>> org.trialox.platform.launchbundle [17] cannot be uninstalled, since it >>>> is >>>> either starting or stopping.) >>>> org.osgi.framework.BundleException: Bundle >>>> org.trialox.platform.launchbundle [17] cannot be uninstalled, since it >>>> is either starting or stopping. >>>> at >>>> org.apache.felix.framework.Felix.uninstallBundle(Felix.java:1901) >>>> at >>>> org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:823) >>>> at org.trialox.platform.launchbundle.Main.start(Main.java:101) >>>> at >>>> >>>> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) >>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1458) >>>> at >>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:984) >>>> at >>>> org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:263) >>>> at java.lang.Thread.run(Thread.java:619) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> >>> -------- >>> Christopher Armstrong >>> carmstr...@fastmail.com.au >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> For additional commands, e-mail: users-h...@felix.apache.org >>> >> >> -- >> >> >> Ascert - Taking systems to the Edge >> r...@ascert.com >> +44 (0)20 7488 3470 >> www.ascert.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > > > -- > Karl Pauls > karlpa...@gmail.com > > --------------------------------------------------------------------- > 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
