> Recently I observed some some interesting behaviors while trying to use JRE > defined property called "java.protocol.handler.pkgs" to locate > URLStreamHandler. Yes, I know I should be using OSGi URL handler service, > but that's a separate discussion. Here are my observations: > > 1. I don't see any Handler for *bundle* scheme. So, if I disable urlhandler > service (felix.service.urlhandlers=false in config.properties), then any URL > with *bundle* scheme can't be used. Should there not be handlers for all > Felix defined schemes?
I don't think that the bundle protocol handler would be generally useful. It's only meaningful in the context of a framework and as such implementation specific as well... > 2. framework/URLHandlers.java, which is responsible for processing > "java.protocol.handler.pkgs", prefixes default pkg names by user supplied > value. So, if I specify p.q as the value of that system property, then the > pkg list becomes: p.q|sun.net.www.protocol|..." This was causing a > LinkageError for me while trying to locate a handler for jar scheme. When I > set the property as sun.net.www.protocol|p.q, things started working. I have > to investigate a bit more on the LinkageError with a smaller test case. Sounds strange. Please try to get this test case done so that we can see whats going on. > 3. URLhandlers.java calls m_secureAction.forName(className) to see if a > handler is found in a package or not. This eventually calls Class.forName() > which uses caller's classloader to load className. Since caller is always a > Felix class, SecureAction to be precise, it is only able to locate handlers > that are visible to classloader that loaded Felix. Should Felix be using > Thread's context class loader to find the class? Well, the current approach wasn't intended to be an extension mechanism. All it should do is to allow for other jvm implementations. I think it is problematic to try to use it for other purposes. One issue is that handlers are cached by the jvm iirc. It would be sort of strange to use the context class loader in this case because one would need to control all threads that trigger handler loading. It almost sounds to me like you are trying to build your own URLHandlers outside of the framework. Could you maybe let us know a bit more about what it is you need? Maybe there is a different solution to your problem... regards, Karl > Thanks, > Sahoo > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Karl Pauls [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
