I see your ICLA has now come through. ;) Matt
On Thu, Apr 12, 2012 at 4:39 PM, Matt Benson <gudnabr...@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_hon...@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_hon...@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:strub...@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-unsubscr...@commons.apache.org >>>For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
