On 23/10/2012 01:01, Konstantin Kolinko wrote: > 2012/10/17 Mark Thomas <ma...@apache.org>: >> On 17/10/2012 15:07, Konstantin Kolinko wrote: >> >>> 1. Are <PreResource> and <PostResource> able to inject individual files? >> >> Not yet, but that should be relatively simple to implement. >> >>> 2. I am -1 on removal of VirtualWebappLoader. >>> >>> The feature of injecting additional classpath entries into >>> WebappClassLoader.super.addURL() is an important one and I use it a >>> lot to inject external dependent libraries into web applications. >>> >>> I do not like your approach as a replacement, because classpath >>> entries handling (jars handling) in URLClassLoader and in >>> WebappClassLoader is based on different requirements. I think that >>> URLClassLoader serves better for external libraries >> >> Could you expand on this please. I'm struggling to see the difference >> between using the VirtualWebappLoader and mapping JARs into WEB-INF/lib >> and directories containing classes onto WEB-INF/classes >> > > There is a difference, > but after thinking about it I am removing my veto.
OK. Thanks. I might start porting this back quite soon as I have some test cases I want to write that would be a lot easier with the new implementation. > 1. If I consider the following two operations > a. adding a library to the classpath > b. maintaining it as a proper webapplication resource > > if "a." is all that I need, then having (a. + b.) will have an > additional overhead. Yes, there is an additional overhead. Exactly what that overhead is will vary on a case by case basis and I'd hope was at least partially compensated for by a simpler resources implementation. > What VirtualWebappLoader does is essentially similar to putting a > library into $CATALINA_BASE/shared. > > > I know of the following overheads: > 1.1.) An additional resource participates in resource lookups > > In my use case I insert a dozen of libraries into the classpath. I do > not use VirtualWebappLoader directly, I am calling the API that it > uses - WebappLoader.addRepository(). > > Looking at the example of Tomcat 7 aliases, if you have 100 aliases > then every resource lookup will perform a linear search through all > the aliases. > > Regarding my question of injecting individual files into resources - > maybe it would be better to support collections of individual files > rather than files themselves. E.g. wrap a dozen of libraries into > single collection for "/WEB-INF/lib". You could place all the JARs you wanted to map in a single directory and map that although if you want a single, central library of JARs from which to work from you'd need a custom ResourceSet implementation which should be pretty simple for the situation you describe. > This way the individual libraries will be enumerated only when one is > searching for something with a prefix of "/WEB-INF/lib". Searching for > any other prefix will skip the libraries. Agreed, with a custom ResourceSet. Rather than a custom ResourceSet, the ResourceSet implementation could be part of the standard distribution. > 1.2.) WebappClassLoader#closeJARs(..) > WebappClassLoader closes unused JARs after some time of inactivity. > > Discussed here: > https://issues.apache.org/bugzilla/show_bug.cgi?id=52448 > > I do not see much sense in this jar closing feature. Anyway, > URLClassLoader keeps its jars open. > > (Not much of an issue, though. If it were a real nuisance, we can make > it configurable). It is probably worth some svn archaeology to see if we can figure out why this feature was added in the first place. > 2. There will be small difference with handling of > VirtualWebappLoader#setSearchVirtualFirst( ) property. > > With VirtualWebappLoader and searchVirtualFirst=true the order of > precedence when looking of a class is > {external classes and libs, webapp classes, webapp libs}. > > With webresources I think the order will be different, because > WEB-INF/classes takes precedence over WEB-INF/lib: > {external classes, webapp classes, external libs, webapp libs}. > > It is a little nuance. I do not think there will be much confusion from it. Agreed. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
