Steven, As far as URLStreamHandlerService goes, I can see two problems you might be running into.
1. You're hitting a "built-in" protocol as determined by the implementation of the URL handling service's URLStreamHandlerFactory. In the case of Equinox's, the system property "java.protocol.handler.pkgs" is checked for these built-ins. 2. You aren't hitting a "built-in" known by the URL handling service's URLStreamHandlerFactory, but an "http" url is looked up before your custom URLStreamHandlerService is registered. In this case, the Sun URL implementation's getURLStreamHandler(String protocol) method will receive a null handler from the OSGi factory and eventually look for "sun.net.www.protocol.http.Handler". Once URL finds a handler, either from one of the built-in packages or from the registered factory (the OSGi URL handler service in this case), that handler instance is cached in a Hashtable and returned immediately from that point on. The only time that Hashtable is cleared is when the URLStreamHandlerFactory is set, and that factory can only be set once per JVM instance. There may be other possible problems, as I've just taken a cursory glance at the various players involved, but hopefully this will get you on the right track. -Jeremy On 4/13/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:
[ I posted this message originally on 13 April and got no response, so I'm trying once again. The discussion of OBR at the end is perhaps best fit for the Felix development list, but the first question regarding plugging in a different HTTP URLStreamHandlerService seems like it's fit for this forum. ] 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
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
