Werner Punz schrieb:
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!
Actually on a second thought, I like the idea of being able to hotplug
a new loader provided by a library this would reduce configuration. It
still is impossible
to provide it on artefact level though :-(
In either way I would propose following.
First make it the way via configuration that way we can provide
the functionality relatively easy, later add autoscanning
I think this needs further discussion.
I would like to add the changes to the 1.2 trunk codebase though because
this is my current development build for the groovy stuff.
I think they are not very big, so it is not really critical to provide them.
We still can refactor that later on.
That way I can provide a working groovy extension as soon as I am able
to commit my code into the new project out of the box.
(Sorry for the change of mind in this case I just want to have people
testing the stuff asap)
