The Next Great Thing: An Application Framework

[Uclio Work]

> ... because they would introduce problems they won't notice when running
> outside OSGi. Take the 2.0 FXMLLoader example which works perfectly in
> an outside OSGi-World because there's one classloader which sees everything.

Do you mean maybe "when running inside** OSGi" ? There's a huge 
difference, Tom :-)

> Other problems are e.g. dealing with CSS-Files (e.g. in pre 2.0 they
> didn't used the URLs appropriately and so OSGi-Paths didn't work
> appropiately) and resources defined in there like images, ... but also
> Java-Classes (-fx-skin!).
>
> So if they are not running in OSGi they will most likely introduce other
> such problematic classloading things - some of them fixable e.g. using
> tricks like setting modifying the ContextClassLoader (the FXMLLoader
> problem in 2.0) and others unfixable like the -fx-skin stuff in CSS.
>
> Writing a library without using it on OSGi while doing so will lead to
> all sorts of problems - and if the JavaFX team would integrate our
> modifications into their source we are the ones responsible to ensure
> they'll work in future versions as well.

I totally agree with you, Tom. Having JFX made OSGi-aware by the JFX 
team would be the best option. But honestly, how much do they care at 
this very moment ? Maybe Richard can shed some light about this.
Moreover, I am not aware of resources available to the team, butthis 
seems anyway to be a huge work, if not a refactoring of the entire platform.

I guess that as long as the platform does not reach a certain level of 
maturity, so that the burden for the team starts to decrease, we should 
suggest changes as we encounter potential problems.

But, hey, if someone in the JFX team says... "No, we need to have JFX 
OSGi-aware now"... I'll be very happy

> You did not yet mention what you had to modify e.g. in the
> NativeLibLoader to make things work.

Because they have hardwired the path where the native libs have to be 
placed. Therefore the usual OSGi approach, that is having the 
Bundle-NativeCode header in your manifest with the OSGi engine doing 
loading,  fails since the findLibrary of the OSGi ClassLoader can't 
resolve the location of the libs.

Lucio