Hey Martin, interesting questions. Here are my 2 cents on this.
You mentioned the two "unspecified" cases... 1) if an error occurred, it is even worse than an Exception. Java doesn't make any assumptions about the possibility of recovery from an error, so it doesn't make sense to continue the start-up behavior. After an error the only logical consequence is to try a shut down, but even this might fail (just think of an OutOfMemoryError). In a former project we were thinking about catching such an Error in the thread group and by de-allocating some reserved memory being able to print valuable status information. In practice we have withdrawn this because of the unlikely hood of success. In such a case, all bets are off. 2) this is the business of the bundle provider. You know that you have to do you're own housekeeping within you're bundle boundary, the spec makes it pretty clear as you quoted already (use finally, listeners, heartbeat monitors, etc, what ever is appropriate). The core problem for OSGi here is to figure out which bundle is responsible for what resource in order to help the developer. Of course, OSGi can start each bundle in its own ThreadGroup and by this being able to track usage to some extend, but this is not efficient (too many threads, potential synchronization problems, etc.). In general Java is extremely limited when it comes to resource management and assuming you can controll this in your framework is doomed to fail (f.i. you can't prevent a bundle from creating a OutOfMemoryError, no matter how hard you try - if it is allowed to be activated it can crash your JVM). To wrap it up, not specifying the Error case makes sense, when you look at it from a contract point of view. You can't guarantee anything, so why "specify" it. Although an advise like be kind and die gracefully would be nice ;-) The same applies for resources. Trying to control them within the JVM is some what pointless (or at least not efficient till now) - unfortunately. Cheers, Mirko On Mon, Feb 16, 2009 at 12:49 PM, Cornelius, Martin (DWBI) <[email protected]> wrote: > I'm wondering about this question : Is there is a default way in which > uncaught throwables, i.e. instances of RuntimeException or Error, are > handled within OSGi ? > > > > So fa i found partly answers of this question: > > - In paragraph 4.3.6 of the core spec, i found this statement: If the > start(BundleContext) method throws an exception, the Framework must mark the > bundle as stopped and send out STOPPING and STOPPED events but it must not > call the Bundle Activator stop(BundleContext) method. > > - The method stop(BundleContext) may also throw an execption, but i found no > hint in the spec what should happen in this case. However, the javadoc of > the core API states the following: if this method throws an exception, the > bundle is still marked as stopped, and the Framework will remove the > bundle's listeners, unregister all services registered by the bundle, and > release all services used by the bundle. > > > > This leaves some cases unspecified: > > 1.) what should happen, if an Error is thrown from start(BundleContext) or > stop(BundleContext). > > 2.) what should happen, if some 'worker thread' started internally within a > bundle throws an uncaught RuntimeException or an Error from it's run() > method ? > > > > To me, it looks in many cases reasonable to shut down the complete VM if > such uncaught exceptions occur, because it might be in an unforeseen, > inconsistent state. However (at least with ApacheFelix) this does not happen > by default. Of course i can code this explicitely whenever a thread is > started in my code, but this does not help me with third party libraries > (like Jacorb or QUARTZ), that create threads internally. For this reason, i > would like to install a general 'uncaughtException' handler for a specific > bundle or the complete OSGi framework. I have been searching the spec and > the mailing lists on how to achieve this behaviour, but found nothing so > far. > > > > Have i overlooked something, or have these cases intentionally been left out > from the spec ? > > > > thanks in advance for any hints, Martin > > > > > > ************************************************ > The information contained in, or attached to, this e-mail, may contain > confidential information and is intended solely for the use of the > individual or entity to whom they are addressed and may be subject to legal > privilege. If you have received this e-mail in error you should notify the > sender immediately by reply e-mail, delete the message from your system and > notify your system manager. Please do not copy it for any purpose, or > disclose its contents to any other person. The views or opinions presented > in this e-mail are solely those of the author and do not necessarily > represent those of the company. The recipient should check this e-mail and > any attachments for the presence of viruses. The company accepts no > liability for any damage caused, directly or indirectly, by any virus > transmitted in this email. > ************************************************ > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
