commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for class path scanning / class metadata
Date Fri, 13 Apr 2012 22:19:17 GMT
I see your ICLA has now come through.  ;)


On Thu, Apr 12, 2012 at 4: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
> IP.
> Matt
> 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 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:

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

View raw message