On 14 Jan 2008, at 23:40, Brian Stansberry wrote:
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.
Ok, I'll change this in favour of hard coded constants and re-tag.
Sorry about this, bad assumption on my part that all AS5 classloaders
could expose URLs.
Manik
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org