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" <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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org