felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: URL Handlers Service
Date Fri, 07 Oct 2005 18:26:59 GMT
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
>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

View raw message