Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
Am 14.11.12 08:13, schrieb Gunnar Wagenknecht: Am 14.11.2012 01:30, schrieb Neil Bartlett: I really feel that the problem is in the launcher, so that's where it needs to be fixed, i.e. by setting the osgi.parentClassloader=app system property. I agree. So the wrong property is only used if the Equinox is launched using the binary executable or also when launched using java -jar org.eclipse.osgi...? Please note that we can't simply change the launcher to use the ext-classpath because then we'd most likely break other Eclipse plugins! We only change the classpath for a specific fragment. At least this is how I interpreted Tom Watsons suggestion to use the above format. I think the dilema is that anything that requires a fix will make adoption harder because people won't be able to use released versions (eg., Juno) for JavaFX development. Is that correct? Right. I could live with the fact that Juno SR2 introduces support for such a custom header and people are required to use that one - the more eclipse version can be supported the better in general. Tom -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindl geschäftsführer/CEO eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone++43 512 935834 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
On Wed, Nov 14, 2012 at 11:34 AM, Tom Schindl tom.schi...@bestsolution.atwrote: Am 14.11.12 08:13, schrieb Gunnar Wagenknecht: Am 14.11.2012 01:30, schrieb Neil Bartlett: I really feel that the problem is in the launcher, so that's where it needs to be fixed, i.e. by setting the osgi.parentClassloader=app system property. I agree. So the wrong property is only used if the Equinox is launched using the binary executable or also when launched using java -jar org.eclipse.osgi...? Please note that we can't simply change the launcher to use the ext-classpath because then we'd most likely break other Eclipse plugins! I really don't think so. I had a brief chat with Tom W about the reason why Eclipse uses the boot loader as its parent. Apparently it dates back to Eclipse 2.x (pre-OSGi) and conflicts with the Xerces XML parser that was being shipped in Sun JREs around that time. You see the irony, I hope back then it was necessary to avoid exposing Eclipse to non-JSR libraries in the extension loader. Now we WANT to expose Eclipse to non-JSR libraries in the extension loader. You can't have your cake and eat it. Why not try running Eclipse right now with osgi.parentClassLoader=app, and find out what happens? We only change the classpath for a specific fragment. At least this is how I interpreted Tom Watsons suggestion to use the above format. I just don't see how it's possible for the framework to change its own classpath for different fragments. Maybe Tom has some ideas. However I think this solution could come with its own set of plugin breakages, if it even works at all. I think the dilema is that anything that requires a fix will make adoption harder because people won't be able to use released versions (eg., Juno) for JavaFX development. Is that correct? Right. I could live with the fact that Juno SR2 introduces support for such a custom header and people are required to use that one - the more eclipse version can be supported the better in general. Tom -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindl geschäftsführer/CEO eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone++43 512 935834 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
I agree that the most simple option is to change the launcher to use the app class loader as the parent classloader. The default for that has been boot for many years. This has provided us with a level of isolation from the extension and application class loaders. We could change the default, but I don't think that has no risk associated with it. I had not thought about the fact that frameworks must fail to install extension bundles with types they do not understand. So it is true that this fragment will fail to install on other frameworks (if they are performing the proper check). In equinox we treat the extension type extclasspath as a special type and for packages exported by such a fragment we delegate class loads to the extension class loader no matter what the parent class loader of the framework is. So it should not matter what the framework's class path is in this case. But don't get me wrong. I would much prefer we did not use this option. In fact I don't even really want to support such a concept of extension system bundle fragments at all in the future since I think it will be difficult to support them if we start running with Java Modularity support in the VM. Even if we do change the default of the framework's parent class loader, we still need a way to configure the system bundle to export the JavaFX packages. Tom From: BJ Hargrave/Austin/IBM@IBMUS To: Equinox development mailing list equinox-dev@eclipse.org, Date: 11/13/2012 04:47 PM Subject:Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX) Sent by:equinox-dev-boun...@eclipse.org Fragment-Host: system.bundle; extension:=extclasspath Would this extension:=extclasspath cause problems to other OSGi-Implementations like e.g. felix? A compliant framework should reject this manifest since the standard directive does not specify a valid value. If you are thinking of having a non-standard, Equinox-specific value for a standard directive, why not just add an Equinox-specific manifest header or Equinox-specific directive? Fragment-Host: system.bundle; x-appclasspath:=ext This does not sound like it would work in general anyway. What happens when the framework is launched from code whose classpath does not include ext? I assume the option here is either use the bootclasscloader for the parent of the classloader used to load the framework or use the current classloader for the parent of the classloader used to load the framework. -- BJ Hargrave Senior Technical Staff Member, IBM office: +1 386 848 1781 OSGi Fellow and CTO of the OSGi Alliance mobile: +1 386 848 3788 hargr...@us.ibm.com ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
Fragment-Host: system.bundle; extension:=extclasspath Would this extension:=extclasspath cause problems to other OSGi-Implementations like e.g. felix? A compliant framework should reject this manifest since the standard directive does not specify a valid value. If you are thinking of having a non-standard, Equinox-specific value for a standard directive, why not just add an Equinox-specific manifest header or Equinox-specific directive? Fragment-Host: system.bundle; x-appclasspath:=ext This does not sound like it would work in general anyway. What happens when the framework is launched from code whose classpath does not include ext? I assume the option here is either use the bootclasscloader for the parent of the classloader used to load the framework or use the current classloader for the parent of the classloader used to load the framework. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
I agree with BJ that it would be better to use an Equinox-specific directive for this Equinox-specific functionality. I believe that Felix should work fine today with the following: Fragment-Host: system.bundle;x-appclasspath:=ext because it would ignore the unknown directive, and would provide visibility of the JavaFX classes via the framework's application classpath. The same would be true of Equinox sans the slightly strange Eclipse launcher. There are implementation challenges with this approach, because the instruction to use the extension loader needs to be passed out of the framework to the launcher. The framework shouldn't actually know what classloader it has been started in, only the launcher knows that. Therefore in order to obey the above directive, the framework would need to actually find the extension loader, which will a sibling of its own classloader. The Java classloader API doesn't provide methods for navigating up and down the tree in this fashion, AFAIK. I really feel that the problem is in the launcher, so that's where it needs to be fixed, i.e. by setting the osgi.parentClassloader=app system property. On Tue, Nov 13, 2012 at 10:57 PM, Tom Schindl tom.schi...@bestsolution.atwrote: Am 13.11.12 23:42, schrieb BJ Hargrave: Fragment-Host: system.bundle; extension:=extclasspath Would this extension:=extclasspath cause problems to other OSGi-Implementations like e.g. felix? A compliant framework should reject this manifest since the standard directive does not specify a valid value. If you are thinking of having a non-standard, Equinox-specific value for a standard directive, why not just add an Equinox-specific manifest header or Equinox-specific directive? Because Equinox already supports it this way and if the change is coming with Java7u something we need to use what is already in the framework. Fragment-Host: system.bundle; x-appclasspath:=ext I'm all for having such a framework specific option, if I got Neil and Tom right only equinox has this strange setting that it does not consult the extension classpath and has to be forced in this direction. So if equinox is willing to implement it, I'll happily use it but if I have the choice of: a) can't run at all on equinox b) only work on equinox I'll go for b). Users of other frameworks would have to create their own fragment, not the prefered solution but well. This does not sound like it would work in general anyway. What happens when the framework is launched from code whose classpath does not include ext? I assume the option here is either use the bootclasscloader for the parent of the classloader used to load the framework or use the current classloader for the parent of the classloader used to load the framework. I let Tom Watson comment on this. Tom -- B e s t S o l u t i o n . a tEDV Systemhaus GmbH tom schindl geschäftsführer/CEO eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone++43 512 935834 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath (e.g. JavaFX)
Am 14.11.2012 01:30, schrieb Neil Bartlett: I really feel that the problem is in the launcher, so that's where it needs to be fixed, i.e. by setting the osgi.parentClassloader=app system property. I agree. So the wrong property is only used if the Equinox is launched using the binary executable or also when launched using java -jar org.eclipse.osgi...? I think the dilema is that anything that requires a fix will make adoption harder because people won't be able to use released versions (eg., Juno) for JavaFX development. Is that correct? -Gunnar -- Gunnar Wagenknecht gun...@wagenknecht.org http://wagenknecht.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
