[REVIEW] Make controller instantiation customizable (original) (raw)
Tom Schindl tom.schindl at bestsolution.at
Thu Dec 15 02:30:42 PST 2011
- Previous message: [REVIEW] Make controller instantiation customizable
- Next message: [REVIEW] Make controller instantiation customizable
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Am 14.12.11 17:58, schrieb Greg Brown:
Let's see if I understand the current logic how the include look up is done with a source like "/my/package/test/HeaderView.fxml".
My current assumption is that you are consulting the current Classloader to locate the file, correct? Yes. The FXMLLoader is running in the JVM of the Tooling (in my case Eclipse but I guess it is the same for Netbeans) to e.g. place the preview next to your editor which naturally has no idea about the classpath found in your project. ... To make FXMLLoader happy I now need to construct an URLClassLoader by inspecting the projects classpath and redefine the Thread-Context-Classloader which has the draw backs outlined in my other Shouldn't the IDE be creating a new class loader to load the preview anyways? It shouldn't be sharing the classloader that was used to load the IDE itself, since that would be a potential security hole (not to mention confusing, since the IDE code shouldn't be visible to the app code).
Yes, I do but i would not need to create a classloader (and in fact I do it already) add the library.jar to the URLClassloader which as outlined in my other post has the drawback on Windows that the jar gets locked until an undefined point in time (at least on Java6).
If you'd allow me to intercept the include look up (my guess is all you extract is an URL to proceed) I would not need to add the jar to the URLClassLoader but provide you the URL for loading through other an IDE look up (=no jar locking).
You could now naturally argue that I'll have to add the library.jar anyways because there one could e.g. use a custom Control in the JavaFX file but that's another story.
Anyways I can work with what is already and there and with the addition of setClassloader() at least the dirty context classloader setting is gone.
I'll wait until the FXMLLoader code is published to take a deeper look in it once more.
Tom
-- B e s t S o l u t i o n . a t EDV Systemhaus GmbH
tom schindl geschäftsführer/CEO
eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 http://www.BestSolution.at phone ++43 512 935834
- Previous message: [REVIEW] Make controller instantiation customizable
- Next message: [REVIEW] Make controller instantiation customizable
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]