Well, if you expect to use the default URLClassLoader for dynamically load some JARs for script executions, you should consider class unloading and caching issue with great care. Especially that you suggest to use attachment of the XWiki for storing JARs. I tell you that by experience, since we execute compiled Groovy from JARs since a year now, and I am at my third implementation (a macro 2.0) of a dynamic solution based on the URLClassLoader (currently too young to confirm that it is fully stable, but that is the most promising one). You should be aware that there is several caching done by the Sun JVM while loading JARs files (the class loader and URLConnection code is in term of extension, a really ugly part of the JVM IMHO): - the JARs is cached localy in /tmp even when UseCaches is false - for all temporary file, a handle is kept forever, the JVM forget to close the file - garbage collection of ClassLoader are not done until all its loaded classes are unloaded - class unloading depends on the GC used and is very JVM dependent (there are several strategies on Sun JVM, that depend on the version, the most advanced being introduced in 1.6.0_04-b12, so recently. Before that, unloading (if any) occurs mainly during heavy memory load only). So, dynamic JAR loading may require/lead to the following: - JVM dependance (my own solution is almost independent, but I have only tune it for Sun JVM currently) - URLClassLoader hacking to better handle JAR file closing (what I currently do) - Full rewrite of your own class loader implementation (the safe way, but an heavy task) I do not want to afraid you, and it would be a pleasure to help in that matter, but I prefer you do not felt in all the traps on the way, since this usually caused the whole system to suffer. Denis Gervalle On Aug 26, 2009, at 17:18, Vincent Massol wrote: