Jason T. Greene wrote: > The injection design makes assumptions about the ClassLoader it is > running in, which we can't do. > 1. ClasspathScanner's constructor assumes that all ClassLoaders are > URLClassLoader, this is not always true, and leads to CCE when it > is not. Yes, due to this the AS fails to start properly w/ a build of the current JBC trunk in it. The classloader in the AS is not a URLClassLoader subclass. > 2. ClasspathScanner.getURLPathFromClassLoader expects only simple > file based URLs (like those returned from URLClassLoader). This > will not work with the AS5 VFS, which uses a custom URL type ("vfs"). > 3. ClasspathScanner.scan assumes that all URLS are on a local > filesystem. This is also not the case. An AS can have http based > deployments for example. > These problems not only prevent compatibility with AS5, they also > cause problems with my maven testruns, since I have to have > useSystemClassLoader set to true, which uses a manifest for > constructing the classpath. > We should remove this scanning code in favor of either hardcoded > constants, or a hardcoded registration process. I hacked in hard-coded constants on my local checkout and am running the AS testsuite with a core JBC build from that. There are issues with the FIELD granularity tests, but the tests that only use core cache look OK.