2010/4/23 Rainer Jung <rainer.j...@kippdata.de>: > There is a previously undocumented VirtualWebappLoader, which extends > WebappLoader and allows to add search paths (repositories) to the webapp > class loader. > >(...) > Since the feature seems to be nice e.g. for > loading or overwriting configs from outside of the war I'm wondering whether > we should actually put it into WebappLoader. > > If so, we should: > > - deprecate VirtualWebappLoader in TC 6 > > - remove it in TC 7 > > - decide, whether we stick to the notation "virtualClasspath" used at the > moment, or "externalRepositories" or similar, which would be more consistent > with the class internals. I have a tendency for "externalRepositories". >
1. The class is commented as "This is not meant to be used for production. Its meant to ease development with IDE's without the need for fully republishing jars in WEB-INF/lib" Essentially it is a wrapper for API that is already provided by WebappLoader, so it is already supported. E.g., just recently we have fixed some class loader locking bugs that occur when running with external repositories (well, fixed in 5.5. In 6.0 that BZ 48903 patch waits for the third vote). I am +1 to move the implementation to WebappLoader and +1 to use the same naming as WebappLoader/WebappClassLoader are using: "external repositories". 2. Regarding proposed "deprecation" or "removal": I am -0 to deprecating this class in 6.0, unless this feature is backported there. In 7.0 we can just remove this class, and add a note to site/trunk/xdocs/migration.xml. I prefer to remove it. 3. Regarding the performance of these external repositories I have some doubts. It is implemented by passing the JARs an URLClassLoader. I hope that these JARs are not reopened and scanned for each class that is being loaded (have not tested/debugged here, so it is a speculation). It is a bit strange to combine two JAR handling mechanics in the same WebappClassLoader class. BTW: I know that WebappClassLoader#closeJARs() closes JARs after some time (after webapp started and after some time (90 seconds + average time between background cycles) after last class load activity, IIRC) and then reopens them all next time a class from the webapp is loaded. If we face something like that I would like to have it in our hands/have it controllable. If it is provided by a base class (URLClassLoader), we might not have much control there. 4. VirtualWebappLoader serves as an example how to configure <Loader> element in the context file. The configuration attributes for WebappLoader are usually provided by StandardContext class, so it is reasonable to add these new attributes there as well. PS. Among the classes in o/a/catalina/** of trunk the WebappClassLoader is the second by its size (116 Kb/3241 lines), and StandardContext is the first (184 Kb/5994 lines). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
