Interesting stuff. (Hopefully this thread is still alive) I like your third approach best too.
The first approach excludes the 2nd, 3rd, ... framework from adding new handlers which depending on the handler and how the framework uses it might be very problematic and in some cases might prevent the framework itself from running. The second is also problematic for the reason that multiple handlers for the same protocol might be registered. For good or bad I've seen to many URLHandlers that have implied context that they believe is global. (For example, a bundle URLHandler that uses a BundleContext instance to do the lookup. There might be clever ways around this but dealing with collisions is not fun - (neither is documenting how they get resolved). The third tries to deal with the context problem so... I agree with you and think it's the best approach to look into. 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. -- 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. Note: (This means a definition for the ContextClassLoader and ThreadLocal also has to come from the "parent") -- 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? -Simon -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Sunday, October 02, 2005 9:32 AM To: oscar-dev@incubator.apache.org Subject: URL Handlers Service Hello, I am in the process of re-implementing the URL Handlers service for Felix. The URL Handlers service is essentially a singleton, since it must make calls to URL.setURLStreamHandlerFactory() and URLConnection.setContentHandlerFactory(), which are singleton methods. However, I would like to consider approaches for making it work when multiple instances of the framework are in memory at the same time. As far as I can see, there are at least three approaches: 1. First framework instance wins, every other framework instance is out of luck. (However, they will be able to use the stream and content handlers of the first framework instance implicitly.) 2. All stream and content handlers for all framework instances are aggregated; thus, individual frameworks use a merged set of handlers. 3. Framework isolation is maintained, i.e., bundles in a given framework instance only see handlers registered by bundles in the same framework instance. For me, #3 seems like the way to go, but I am not sure how easily this can be achieved. My thought was to create a static implementation of the URL Handler service with which each framework instance would register upon creation. When asked for a handler, I imagine that the URL Handlers service would always return a handler proxy (except for built-in handlers), even if no handlers existed, in which case the proxy would just throw some reasonable exception when it was invoked. The reason to always return a proxy is somewhat complicated, but is related to the fact that the JVM libraries cache the answer in some cases and also because some framework instances may have handlers registered and other may not, thus the distinction between having and not having a handler is a little murky. When a handler proxy is invoked it could use SecurityManager.getClassContext() to get the call stack of classes and walk up the call stack to get the first class that is loaded from a bundle class loader. From the bundle class loader it could then find out to which framework instance the bundle belonged and use this information to find out if the framework instance has a registered handler service that matches the request. If not, it would throw an appropriate exception, if so the call would be delegated to the handler service. Of course, there are probably a lot of little details I have not thought about, but this is a general outline of how I am thinking of approaching the problem. Also, I am figuring that we can optimize the single framework instance case so that it doesn't have to do a lot of extra work if only one framework instance exists. Comments are welcome. -> richard This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
