Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of gudnabrsam@gmail.com
 designates 209.85.160.43 as permitted sender)
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
In-Reply-To: <CBAC93B7.1E815%charles_honton@intuit.com>
References: 
 <79E039646D52C14E8807917F748999F004CC2F72@QYNPRDEXMBXAP04.corp.intuit.net>
	<CBAC93B7.1E815%charles_honton@intuit.com>
Date: Thu, 12 Apr 2012 16:39:03 -0500
Message-ID: 
 <CAE9L6G1od4FjEuk2v2UFg2OBjG38WDn=M6o6_12_rj8DB0ermQ@mail.gmail.com>
Subject: Re: [classscan],[meiyo],[sandbox] Sharing a concrete proposal for
 class path scanning / class metadata
From: Matt Benson <gudnabrsam@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.) =A0You can see the cod=
e
>>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. =A0Finding 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. =A0The code allows gc reclamation of the bcel objects to
>>minimize memory footprint. =A0The 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 =A0be 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