Hmm, I will have to take a look at that. I'm using the ResolverUtil in Log4j2 that several other projects use. It works well but I discovered it was taking about .4 seconds to capture all my plugins. Instead, I am now running that step for all the plugins provided by Log4j2 during the build and saving the serialized Map to be read at startup. That reduced the overhead of loading the plugins to almost zero.
Ralph On Apr 11, 2012, at 1:47 PM, Honton, Charles wrote: > Mark, > > Please look at my implementation - http://chonton.github.com/meiyo-sandbox/ > (I've accidently trashed my source respository, which I'll clean up > tomorrow.) You can see the code through the javadoc and jxr reports. > > The implementation tracks classes per location (jar or folder), with multiple > locations per classloader, up to and including the bootstrap classloader. > Finding class information delegates the search up the parent chain, mirroring > the classloader pattern. > > Additionally, the implementation includes a registry of classloader > information, so that multiple users need not introspect each classloader > multiple times. The code allows gc reclamation of the bcel objects to > minimize memory footprint. The registry holds weak references to the > classloaders, so that the classloaders may be reclaimed. > > Regards, > chas > > -----Original Message----- > From: Mark Struberg [mailto:strub...@yahoo.de] > > ... We need to provide class scanning on a per-ClassLoader level. Many > frameworks (EJB, CDI, ...) need to take care about Class visibility and might > even have to deal with 'shared-contexts'. Thus the commons-classscan as well > as xbean-finder must be aware of the ClassLoader hierarchy. Especially in > multi-webapp environments this might (as side effect) also bring a pretty > neat performance improvement as we don't need to scan those shared class > paths redundantly! > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
