Per Section 11.3.2 of the OSGi R4 specification, is it correct that one cannot replace the default behavior of java.net.URL's openStream() and openConnection() methods (that is, its interaction with URLStreamHandlerFactory) for a "built-in" protocol such as HTTP?
,----[ Section 11.3.2 -- Built-in Handlers ] | It is thus not guaranteed that a registered URLStreamHandlerService | object is used. Therefore, built-in handlers should take priority over | handlers from the service registry to guarantee consistency. The | built-in handlers, as defined in the OSGi execution environments must | never be overridden. `---- We have our own HTTP client that we'd like to use in lieu of the built-in Java one, in particular to do resource caching beyond what's possible with the java.net.ResponseCache interface. I can't see any way to intercept calls to URL.openStream() or URL.openConnection() without creating a whole new URL scheme (say, "myhttp") that would cause our own URLStreamHandler type to be used for HTTP URLs. Have I overlooked a customization option here? Going further: My main motivation is to stop OBR from actually using the URL instances it consumes; I'd prefer that it treat them as URIs and rely on a resolver interface to get from URI to InputStream, rather than using URL.openStream() directly. With such an interface, I could hook in my own HTTP client without clashing with Java's built-in URLStreamHandlerFactory system. -- Steven E. Harris _______________________________________________ OSGi Developer Mail List [EMAIL PROTECTED] http://www2.osgi.org/mailman/listinfo/osgi-dev
