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.
This is urgent because it prevents the CR3 release from going out.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com