Re: [equinox-dev] Equinox, PDE and packages from the ExtensionClasspath

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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



BJ Hargrave---11/13/2012 04:47:16 PM---> > Fragment-Host: system.bundle; extension:=extclasspath >

From: BJ Hargrave/Austin/IBM@IBMUS
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx

---

> > 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 hargrave@xxxxxxxxxx

office: +1 386 848 1781 mobile: +1 386 848 3788

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev