Bernhard Huemer schrieb:
To clarify that a little bit more:
I'm more or less suggesting to introduce class loader extensions as
well, but I don't think that they should be stored centrally. Instead I
think each artifact should be able to provide the class loader extension!
We are talking about several issues here
first of all you want to provide something along the lines of
viewHandler coded in groovy has to provide the classloader it has to be
loaded from, here we have a hen and egg problem a groovy file awaits the
code so that it can be loaded and the loader which has to interprete the
file has to come from the groovy file itself!
That does not work, the jar itself however could bundle its own
scriptlign loader which then would automatically added to the chain.
That theoretically would work, if we add classpath scanning as well (and
again slow down the startup in this area)
However the approach that an artefact should provide its own classloader
information is not possible in the scope of scripted extensions.
Secondly there is not the metadata even on the jsf side to allow that,
unless you scan for special implementation details outside of the spec.
Heck even on the java side you have to load the class first to get the
classloader information for the class!
The only thing possible would be some autoscan for classloaders in the
classpath which have to be added to the chain!
