Niclas Hedhman wrote:
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?
ConfigurationUtil is dependent on the framework Configuration and DefaultConfiguration.
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.
Is it just ExceptionHelper or is it anything in the avalon-composition-impl-SNAPSHOT.jar. If you try to load the class org.apache.avalon.composition.util.StringHelper class - do you get a similar failure? If yes - then it sounds like the jar file is corrupt.
What happens if you use the binary download? http://www.ibiblio.org/merlin/distributions/20030901/ Do you experience the same problem?
<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???
I doubt it. The URLs are created using file.toURL(). The resulting urls are passed to the URLClassLoader. I.e. nothing special going on.
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.
Probably not - unless you have a security policy file in place. JVM default is running with all permission.
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.
But the real interesting thing is what happens if you try to load StringHelper from the same package.
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.
Don't think so. Others are running on RH without problem.
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...
It cannot be this - if true, the sky would fall on our heads.
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.
Umm, this is much more than an error message. The class that is being reported on just happens to be the ExceptionHelper class. What is probably is that it is an issue with a specific jar file. We can confirm that by replacing jars in you build with jars built by someone else. That at least tells us if this is a general problem or a problem specific to your machine.
For now, is everyone running Windows??
No. Windows, and Linus are both validated.
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
