commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <>
Subject Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for class path scanning / class metadata
Date Thu, 12 Apr 2012 21:16:08 GMT
Repository ( and Reports
( have been updated.


On 4/11/12 1:47 PM, "Honton, Charles" <> wrote:

>Please look at my implementation -
> (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.
>-----Original Message-----
>From: Mark Struberg []
>... 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:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message