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 Mon, 16 Apr 2012 18:51:47 GMT

No commonality with meiyo.  All code written by myself with no Intuit
claim on IP.  I've submitted a ICLA; working on getting the CCLA updated.


On 4/12/12 2:39 PM, "Matt Benson" <> wrote:

>Hi Chas,
>  Thanks for getting the repo back into a nicer state.  Does this
>codebase actually have any common pedigree with [meiyo] (seemingly
>no)?  The answer would dictate how, if indeed, we move forward with
>it; personally I think there is value here especially in that you
>already account for the notion of classloader separation.  AFAICT you
>have no ICLA on file and Intuit's CCLA lists individuals, none of whom
>is you.  ;)  Hopefully this code was written on your own dime anyway,
>but only you and Intuit can say whether they have any claim on this
>On Thu, Apr 12, 2012 at 4:16 PM, Honton, Charles
><> wrote:
>> Repository ( and Reports
>> ( have been updated.
>> Regards,
>> Chas
>> 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
>>>(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:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message