Dear OO Base team: Alternative subjects * hierarchy in Java class loading * default Java class loading by delegation-to-parent * library overwriting and hijacking from directories of parent class loaders * loophole for virus or rogue library code through parent class loaders
References: Understanding Class.forName() - loading classes dynamically from within extensions; author: Ted Neward, 2001-05-24 www.javageeks.com/Papers/ClassForName www.javageeks.com/Papers/BootClasspath www.javageeks.com/Papers/FindingLoadedClasses I do not know which section of OO Base code to inspect in order to find out whether Class.forName() calls are used in OO Base 2.0.3. Based on the explanation by Ted Neward (see references), the Java default delegation of class loading to parent class loaders seems to be a likely candidate reason for this problem. All Java application programs are subject to library version conflict (or even malicious virus libraries) if the default delegation of class loading is used. Merely putting a different version of *.jar library into the directory designated for one of the parent class loaders is all that it takes to mess up the function of application programs. This problem may even occur for libraries of identical version if state variables are used and maintained by library methods. There is a way to eliminate this problem, if this is indeed the cause. Java application programs, including OO Base, should obviate the default delegation of class loading by replacing Class.forName() calls with alternative approaches as illustrated by Ted Neward. Ray --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
