When I remove the JDBC jar to avoid that part of the build I get the next error:
chainsawCheck:
[echo] Chainsaw dependant libraries present.
build.chainsaw:
[javac] Compiling 119 source files to C:\Java\code\jakarta\logging-log4j\dist\classes ^
[javac] C:\Java\code\jakarta\logging-log4j\src\java\org\apache\log4j\chainsaw\plugins\PluginClassLoaderFactory.java:
77: cannot resolve symbol
[javac] symbol : constructor RuntimeException (java.lang.Exception)
[javac] location: class java.lang.RuntimeException
[javac] throw new RuntimeException(e);
[javac] ^
[javac] C:\Java\code\jakarta\logging-log4j\src\java\org\apache\log4j\chainsaw\plugins\PluginClassLoaderFactory.java:
90: cannot resolve symbol
[javac] symbol : constructor RuntimeException (java.lang.Exception)
[javac] location: class java.lang.RuntimeException
[javac] throw new RuntimeException(e);
[javac] ^
[javac] 2 errors
BUILD FAILED
This is a relatively recent commit by Paul. I've complained about it in the past. Paul, what is current your take on the PluginClassLoader et al.?
Changing the way the exception is thrown will make it JDK1.3 compatable. I still think that Chainsaw using a custom classloader is fine because Chainsaw is a standalone application. Having said that, the whole Classloader hell with regard to having a DB/JMS Receiver needing the driver jars in the same or above classloader has pretty much left me with such a bad taste in my mouth I'm very close to the point of dropping it altogether. It could just as easily be accomplished via a .bat/.sh script that adds jars to the classpath, but that would mean the Webstart version of Chainsaw could never use DBReceiver/JMSReceiver and the .bat/.sh version would need some other method to determine if there is an update available. Sometimes that's just The Way It Is.
cheers,
Paul Smith
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
