[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.schindl@xxxxxxxxxxxxxxx> wrote:
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.
