Kaegi, Simon wrote:
Interesting stuff. (Hopefully this thread is still alive) I like your third approach best too.
Well, I don't know if the thread is active, but this issue still is. I have started a first pass of the third approach and I will see where that takes me.
You mention your static URLHandler implementation. If I'm understanding your approach you're thinking of having something like the org.osgi stuff and your "static" implementation in a parent classloader. (?) One thing to keep in mind is that the classloader calling the two singletons setXXX methods will not unload until the VM is shutdown. It's definitely a good thing to be able to completely start, stop, and fully unload the classloader of instances of the framework.
I don't know the precise approach, but you make a good point. I would expect that we are out of luck for unloading the classes that call the setXXX methods. However, I would expect that the implementation would allows us to completely stop the framework instances. Feel free to prod on this issue when I get something available. :-)
Figuring out which framework to query for a Handler is tricky. Walking the stack might be the easiest way. (The stack walker sounds similar to Eclipse's ContextFinder although with slightly different intent.) Some other approaches to think about ... for threads created and destroyed by the framework you could use a ThreadGroup or a ThreadLocal to help find your context. for threads entering the framework from outside you might set/unset the ContextClassLoader with a transparent wrapper on entry/exit.
This might be possible, but it seems like it is less likely to cover all the cases. I have to admit, though, that I have never experimented much with these mechanisms.
To the best of your (or anyone's??) knowledge, apart from the URLHandlerService are there any other parts of OSGi R4 that will prevent multiple instances of the framework from running correctly in one VM?
Off the top of my head, I don't know...perhaps the security manager could be problematic...
Excellent feedback, thanks. -> richard
