When SB loads an FXML document, it first creates a url class loader with
all the JAR files discovered in the library and passes this class loader to FXMLLoader.

This basic mechanism works fine for most custom components.

However if the custom component creates its own contents using FXMLLoader,
the mechanism above works only if the custom component propagates the
class loader it has inherited to FXMLLoader (see DTL-6736).

This requirement might be confusing for an FX developer using SB : he develops
and tests his component outside SB and everything works fine without any
class loader propagation ; when he tries his component with SB, the component
breaks on ClassNotFoundException until he adds the logic to propagate the
class loader.

SB could avoid this requirement by setting the thread context class loader.
With this setup, class loading in SB would be closer to the class loading
in the IDE : a component that works in the IDE would also work in SB without
specific code addition.

However there are some downsides:
1) thread context class loader is security sensitive topic
2) is it really the right thing to do ? in other context (like OSGI class loader),
    the custom component will still have some issue and the only clean solution
    might be the logic which propagates the class loader
...

To be investigated a bit more.