And don't understand what exactly you mean. :-)
Install it where?
Once MC-Kernel is shutdown, all beans are uninstalled == reverted lifecycle invocation.
What you do during install/uninstall is up to you.
Perhaps ProfileService with its serialization could help you here,
saving some contextual state.
e.g. don't do X since you already did it in previous run
Hm, maybe. Perhaps this kind of thing should just be outside the purview of the MC altogether, or perhaps it's just a bad idea in general. I would have liked to provide a mechanism where you could deploy and undeploy URL protocol handlers but I don't think it's going to be possible without introducing an additional API (which I guess isn't out of the question either; it's just not as elegant as I'd like).
OSGi had to introduce an additional API to cover this use case, because of the same issues you are identifying.
I should clarify my last statement.
OSGi have a service called the URL Handlers service and it is responsible for providing a mediation layer between the JDK classes and any dynamic handlers which may be registered.
The service handles two aspects, IIRC, the URLStreamHandlers used through URL and the ContentHandlers used through URLConnection. Both of these classes cache any handlers discovered and therefore prevent them from being modified dynamically.
To get around this restriction OSGi will register proxies on behalf of the ContentHandlers and URLStreamHandlers and these proxies are responsible for delegating to the active handlers services or responding with appropriate faults.
I believe this is the issue you are facing, apologies if it is not.
There should be more details in the OSGi specs and I can dig them out if necessary.
Yup, this is the basic issue. As it happens, we've hacked our way past it for now. But yeah I think the proxy notion is the way to go (eventually). The problem I had was that the actual handlers implement all protected methods, so unless you use reflection or similar tricks, you can't really proxy to another implementation. So I figure that we could create an interface which pluggable URL handlers must implement, and proxy to that. Someday. :-)
So I figure that we could create an interface which pluggable URL handlers must implement, and proxy to that. Someday. :-)
This is precisely what OSGi have done, created a new interface which reflects the URLStreamHandler methods and then the proxy can invoke them directly. :)