commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <Charles_Hon...@intuit.com>
Subject Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for class path scanning / class metadata
Date Mon, 16 Apr 2012 18:51:47 GMT
Matt,

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.

Chas

On 4/12/12 2:39 PM, "Matt Benson" <gudnabrsam@gmail.com> 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
><Charles_Honton@intuit.com> wrote:
>> Repository (https://github.com/chonton/meiyo-sandbox/) and Reports
>> (http://chonton.github.com/meiyo-sandbox/) have been updated.
>>
>> Regards,
>> Chas
>>
>>
>> On 4/11/12 1:47 PM, "Honton, Charles" <Charles_Honton@intuit.com> 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:struberg@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-unsubscribe@commons.apache.org
>>>For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message