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
