Don't know why this message didn't reach - or at least, didn't come back to
me... So resending
----------------------
WARNING; Very long. Written as progress (or lack thereof) is made...
Hi,
Now I have spent more time that I should on investigating this...
Just prior to the ExceptionHelper.packException in the CLIKernelLoader class,
I have investigated the structure and URLs of the CLIKernelLoader's
classloader. It contains the proper JAR files.
The merlin-kernel-impl-SNAPSHOT.jar (containing the CLIKernelLoader) and
avalon-composition-impl-SNAPSHOT.jar (containing ExceptionHelper) are both
part of the lowest level Classloader.
The ExceptionHelper uses the
org.apache.excalibur.configuration.ConfigurationUtil, and it is also present
in the same classloader, in the excalibur-configuration-1.1-dev.jar.
And I have to assume that excalibur-configuration doesn't depend on anything
further... does it?
The ExceptionHelper also uses the Avalon Framework configuration classes, and
they reside two levels up the classloader hierarchy, and should also not be a
problem.
NOW, to investigate if it is the ExceptionHelper that can't be found or one of
the classes it uses (the JVM used to report the wrong class in chained
implicit class loading), I removed everything from the ExceptionHelper. Only
a compilable skeleton left.
Guess what? (waiting for the compile to complete... zzzzzz.....zzzz... )
I get the same problem!!! So it is the ExceptionHelper class itself that can't
be found... Hmmm, looks like JVM bug.
<surprising-finding>
At first I did;
File f = new File( urls[i].toString() );
and the urls[i] contained the "file:/home/niclas....", which resulted in a
relative resolution of the File object, so
f.getAbsolutePath()
returned something like;
/home/niclas/dev/opensource/avalon-sandbox/merlin/target/merlin/file:/home/niclas/dev/opensource....
I thought File was a bit more clever than that!
</surprising-finding>
So I changed it to a
URL[] urls = cl.getURLs();
for( int i=0 ; i < urls.length ; i++ )
{
java.net.URI uri = new java.net.URI( urls[i].toString() );
System.out.println( uri );
java.io.File f = new java.io.File( uri );
if( f.isFile() )
{
java.util.jar.JarFile jf = new java.util.jar.JarFile( f );
java.util.Enumeration list = jf.entries();
while( list.hasMoreElements() )
{
java.util.zip.ZipEntry ze = (java.util.zip.ZipEntry)
list.nextElement();
System.out.print( " " );
System.out.println( ze.getName() );
}
}
else
System.out.println( "File can't be found:" +
f.getAbsolutePath() );
}
ALL classes are retrieved and listed as expected....
Now, IS IT related to the "file:/" relative resolution???
Let's try to modify to "file:///", see what happens...
Same problem, the "file:///" is converted in the File class to a "file:/"
format.
Well...
I am getting exhausted on how to attack this.,,.
I must be in the completely wrong track...
NEW JVM. Downloaded 1.4.2!
Same result.
SECURITY;
I should get a security exception, right... And the testcode above in the
CLIKernelLoader would fail as well.
I am giving up for now...
So what are the findings;
1. If I do cl.getResourceAsStream(
"org/apache/avalon/..../ExceptionHelper.class" ), a null object is returned.
2. The JAR files are in the correct classloaders. The classes are present in
the proper jars, and with the code snippet above the JarEntry-s can be read.
The classes involved in the problem is in the bottom classloader as expected.
3. It is not a problem related to classes implicitly linked in the
ExceptionHelper, as I have tried by removing all external classes from it,
and didn't change a thing.
4. Steve says there are no probs on Windows, so we should be looking at minute
differences between the platforms of handling File.
5. File f = new File( "file:/home/niclas..../xxx.jar" );
f.getAbsolutePath();
resolves to relatively user.dir. Is this handled properly in URLClassLoader.
YES, otherwise nothing would work, would it...
6. URI uri = new URI( "file:/home/niclas..../xxx.jar" );
JarFile jf = new JarFile( uri );
is handled correctly and I can extract all the classes from the jar files.
7. The same result in JDK1.3.1, JDK1.4.0, JDK1.4.1, JDK1.4.2.
8. Maven merlin-dist is very slow, and I would have been a lot further knowing
the -o and properties settings to turn off online mode. The exercise at least
made me frustrated enough to ask about it.
9. This is all about an Error message, and I feel stupid to try to solve it,
but I am just worried it will show up later, deeper, and harder to track.
For now, is everyone running Windows??
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
