[Warning! This will probably be long.]
Ok, I am on the verge of committing my URL Handlers service
modifications to Felix. Currently, URL Handlers is broken for Felix and
this should fix that; it should also add explicit support for using URL
Handlers with multiple framework instances.
The approach I took to support multiple framework instances was what I
outlined before. I created an essentially static URL Handlers service
implementation. All framework instances wishing to use the URL Handlers
service register with the static service upon creation. The static
implementation acts as a multiplexer, routing incoming stream/content
handler requests to handler services inside the appropriate framework
instance. This means that bundles inside one framework instance will
only see handler services from other bundles inside their respective
framework instance. I have done minor testing and this appears to work,
but more testing will definitely be necessary.
The approach I use to route incoming handler requests is to use the
security class context, which gives me the call stack of classes. I then
search backwards to find the first class loaded from a bundle and then
route to the framework that owns that bundle. As an optimization, if
there is only one framework instance, then I just assume that every
request should be routed to it.
I also have a property that allows you to disable the URL Handlers
service, which means that the URL.setURLStreamHandlerFactory() and
URLConnection.setContentHandlerFactory() will not get called if the
service is disabled. However, since this configuration property can be
set on a per-instance basis, if one instance enables it, then these
methods will get called. In that case, instances that disable it will
simply not offer the service to their contained bundles, while instances
that enable it will.
There are a few other things that still need to be finished before it is
completely usable, which are:
* Integrate with "bundle:" resource handling.
* Deal with built-in handlers.
* Implement appropriate security measures.
Even without these, it is still usable. Once these issues are addressed,
then full spec compliance for URL Handlers will basically be done. My
main motivation for now is to deal with built-in handlers properly,
since I am currently just doing a hard-coded check for "file:", which is
definitely a hack. The spec says a bit about dealing with built-in
handlers, so I have to re-read it and see if it enlightens me on this topic.
I will try to get what I have committed next week, if I feel confident
it won't break a bunch of stuff. :-)
-> richard