Bugzilla – Full Text Bug Listing
| Summary: | Setting the Frameworks Startlevel while another thread shut down the framework produce null-pointer | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Christoph Laeubrich <laeubi> |
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | tjwatson |
| Version: | unspecified | ||
| Target Milestone: | Luna M1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Christoph Laeubrich
The StartLevelManager code needs to be cleaned up a bit. It has some static fields for the manager and listeners that should be instance fields that never get nulled out. (In reply to comment #0) > Steps to Reproduce: > 1. One thread issues BundleContext.getBundle(0).start() > 2. Another issuses StartLevel.setStartLevel(...) > 3. java.lang.IllegalArgumentException: null is thrown I suspect step 1) is really to call STOP BundleContext.getBundle(0).stop() on bundle id=0? There are two ways I could see a framework deciding to react to this situation. 1) throw some kind of runtime exception indicating that the StartLevel service is no longer functional (similar to what is done right now) 2) silently ignoring the request because the framework has shutdown. Personally I think option 1 is the better behavior. Just to confirm, this exception did not prevent the framework from shutting down, correct? (In reply to comment #1) > I suspect step 1) is really to call STOP BundleContext.getBundle(0).stop() on > bundle id=0? You are right of course :) > Just to confirm, this exception did not prevent the framework from shutting down, correct? I'm not 100% sure but I think yes, the shutdown is not interrupted. > There are two ways I could see a framework deciding to react to this situation. I would prefer the first since there is nothing the application could do about it it should be ignored, maybe a warning can be issued to the Logservice, because the specification does not state that any exception should be exspected beside IllegalArgumentException and SecurityException, and even it is mandatory to change the startlevel in a background thread, so the caller should never get an exception which is caused by the progress of changing levels! Beside this, I confess its a very rare use-case ;) Another think comes up when while I reading spec: 8.2.2 (changeing the active startlevel) it is stated that each request of changing the startlevel must first be completed before the next one is starte. A little further (8.2.4: Shutdown sequence) it is mentioned, that the framework must behave as if the startlevel is set to ZERO! imo this has the following consequences: stopping the systembundle (and therefore shut down the framework as changing to level 0) should either a) simply shut down and nothing happens if the concurrent levelchange happens before b) first progress the startlevelchange from the other thread and after that shut down c) throw an IllegalstateException or whatever is sufficent when calling framework methods on an already shut down framework Move all 3.8 bugs to Juno. The start-level code is going to be restructured when we prototype OSGi inter-op and Java 8 modules. This is fixed in the twatson/container branch where the restructuring of the framework is going on for Luna. Marking fixed for M1. |