Community
Participate
Working Groups
It would be desirable if Eclipse could be embedded in an environment where the URL.setURLStreamHandlerFactory(...) has already been called. Examples of this type of environment that I've experimented with first hand include most servlet containers and full J2EE App Server. -- Quick Background -- java.net.URL.setURLStreamHandlerFactory(...) allows an application to provide a Factory that will map URL schemes to URLStreamHandlers. Typically this is used internally in the URL class when creating a new instance. e.g. URL myURL = new URL("myscheme://a/b"); In this example the "myscheme" should be mapped to the appropriate URLStreamHandler by the set URLStreamHandlerFactory. The catch is that URL.setURLStreamHandlerFactory is a singleton operation meaning the JVM will only allow this call to succeed once. -- Eclipse (3.1) depends on this call to succeed as it use a few URL schemes (reference, platform, bundleentry, bundleresource) not directly supported in the JVM core. e.g. URL myPlugin = new URL("reference:file:plugins/HelloWorldService_1.0.0.jar"); I'm hoping this enhancement request can serve as a placeholder to investigate alternatives for creating the URLs Eclipse uses internally.
Created attachment 26422 [details] "raw" URLStreamHandler patch for org.eclipse.core.runtime.compatibility For this first set of patches ... the basic approach that I'm working with is to explicitly state a URLStreamHandler when creating a new URL. ... something like URL myPlugin = new URL("reference:file:plugins/HelloWorldService_1.0.0.jar", new ReferenceURLStreamHandler()); This is what I'm calling the "raw" URL creation approach. (A better way might be to do this with direct API support and something like a URL Factory class) For now I'm looking to find out what problems there are with the overall approach. In particular I'm looking for bugs. After using these patches the IDE should still work despiter the lack of a URL.setURLStreamHandlerFactory(...) call. These patches can be applied directly on the R3_1 branch. Let me know if patches for another branch would be better.
Created attachment 26423 [details] "raw" URLStreamHandler patch for org.eclipse.core.runtime
Created attachment 26424 [details] "raw" URLStreamHandler patch for org.eclipse.osgi
Created attachment 26425 [details] "raw" URLStreamHandler patch for org.eclipse.update.configurator
It is unlikely that such an enhancement would make it into 3.1.1. Please make all future patches against the HEAD branch, which is where 3.2 develoment occurs. Thanks for your interest to contribute!
Created attachment 26551 [details] "urlfactory" URLStreamHandler patch for org.eclipse.core.runtime.compatibility This patch uses API support to achieve the same result as the first patch. The result is a little cleaner and much easier to use. To do this I've added org.eclipse.osgi.util.URLFactory which duplicates the java.net.URL constructors with static createURL metyhods. The URLFactory will use Eclipse's URLStreamHandlerFactory to determine the correct URLStreamHandler to use when constructing the URL. I've also added a configuration property "eclipse.sethandlerfactories" -default "true". This property controls whether Eclipse should call URL.setURLStreamHandlerFactory(...) and URLConnection.setContentHandlerFactory(...) during the framework's initialization. -- As per Tom's request this patch is for HEAD.
Created attachment 26552 [details] "urlfactory" URLStreamHandler patch for org.eclipse.core.runtime
Created attachment 26553 [details] "urlfactory" URLStreamHandler patch for org.eclipse.osgi
Created attachment 26554 [details] "urlfactory" URLStreamHandler patch for org.eclipse.update.configurator
This is great. Sorry I have not been able to focus on the patches you have supplied yet. I will hopefully get to your new patches sometime next week.
I have just started to look into your patches. Overall not too bad, but I am bummed that we can no longer use a plain old URL constructor anymore. This means any bundles wanting to run in this type of environment would have to use the URLFactory to create URLs. I understand the reason for this and that it is likely unavoidable ... but it does raise some concerns because we have a lot of third party code which can run in Eclipse and other Java environments. It will be unreasable to ask them to call the URLFactory to create URLs. I think we have a problem with content handlers. URLConnection.getContent uses the current ContentHandlerFactory set with the JVM. Any content handler services registered by other bundles will not be used if we do not set the content handler factory. I may have to add a method to URLFactory to get a content object from a URLConnection. Luckly in eclipse we do not use an special content handler services. But who knows what other third party applications are doing with Eclipse.
Created attachment 26599 [details] "urlfactory-rev2" URLStreamHandler patch for org.eclipse.osgi Thanks for your comments. I'd looked at the ContentHandler problem earlier on... it's definitely not as easy as it looks. I'd initially tried a proxy approach that would use the right dynamic ContentHandler but ran into method access problems. To make it work you'd need the ContentHandler eqivalent of the URLStreamHandlerSetter. The approach you describe (getContent methods on URLFactory) is pragmatic. Here's an updated patch that uses it. I ran into one issue -- in the ee.minimum.jar java.net.ContentHandler doesn't have the getContent(URLConnection , Class[]) method. I see it in the R3 spec document ... should it be there? For now I've just commented out the equivalent URLFactory method.
Created attachment 29912 [details] "Set with Reflection" patch for org.eclipse.osgi This is a prototype of Tom's suggestion for setting the factories with reflection. It also "un"-sets the factories during Framework close. (It includes a related change to EclipseStarter [osgi.close()] which is required to close things down. this is in progress see bug 112646 ) This is a patch on the 3.2 head for org.eclipse.osgi -- no other projects are required. -- Some of this work in this initial prototype is java class library specific - that being said it should work in Sun and IBM JREs.
Created attachment 29989 [details] "Set with Reflection" patch for org.eclipse.osgi Update of patch as bug 112646 has been fixed now.
Created attachment 30010 [details] Improvement to "Set with Reflection" patch I modified the attachment 29989 [details] patch with the following changed - try to call the setURLStreamHandlerFactory and setContentHandlerFactory methods before resorting to reflection - tried to be more general when looking for the static 'factory' field. This may not work if a class library impl has more than one static field of the type we are searching for. - tried to limit the number of fields we are manipulating by nulling the 'factory' field out and then using the standard set method to set the field back to our own factory. We still need to clear the 'handlers' hashtable on shutdown; otherwise we leak our handlers in the cache of the class library. There is still plenty of work to do here when we move to a multiplexed factory implementation.
Created attachment 30092 [details] 3rd attempt at "Set with Reflection" patch This patch fixes some pretty silly bugs in the last patch: - incorrectly used the URLConnection class to find static fields on the URL class - Had a ClassCastException when getting the current ContentHandlerFactory - Did not protect against missing handlers lock field on URL This patch should be much better, and actually work :) I tested this out across the following VMs: Sun 1.3.1, 1.4.2 1.5 IBM 1.4.2, 1.5 J2ME J9 Foundation Simon can you and possibly others take a final look at the patch before I release the code this week. Thanks.
The code changes look good. For the one TODO relating to setContentHandlerFactory, I think the way you left it is safest. It probably wouldn't hurt to reset the handlers but a wait and see approach is fine too. In terms of some testing, in my environment (with a pre-existing URLStreamHandlerFactory and ContentHandlerFactory) I can recycle the platform continuously with no problems. I've also done a bit of memory profiling and can confirm that the framework is being GCed and that everything including the handlers are getting cleared correctly. I'll keep testing, but looks fine from my end.
[contributed patch applied] I released the latest patch into HEAD for Eclipse 3.2
(In reply to comment #18) > [contributed patch applied] > I released the latest patch into HEAD for Eclipse 3.2 The Fix works well with 3.2M4. But I hope You could fix it for 3.1.2. I really need the fix there as well. Please help!
adding "contributed" keyword to patches contributed by the community.
