Injection Code Incompatible with AS and PCache Maven Run

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.

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.

This is urgent because it prevents the CR3 release from
going out.

-- 
Jason T. Greene
JBoss, a division of Red Hat
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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.stansberryredhat.com
_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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
manikjboss.org






_______________________________________________
jbosscache-dev mailing list
jbosscache-devlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev