Basic summary:
It was due to having both log4j.jar and
org.apache.log4j.spi.ThrowableInformation.class
As I mentioned in the previous email, I was concerned I had multiple
versions of my own code. In the process of removing those extra
versions I discovered that JBuilder6 had been compiling some of the
log4j classes on its own. When I removed these extra class files the
problem went away.
Ceki, I should have given you complier and OS information before,
however you hadn't asked.
Thank you very much for the pointer to the problem. I'm happy to say it
was my fault.
Kevin
Ceki Gülcü wrote:
>
> Try the following test program. Compile it using the same compiler
> that produced the binary that generated the VerifyError. Put the same
> log4j.jar file on the classpath. (The one that was used when the
> VerifyError was thrown.)
>
> import org.apache.log4j.BasicConfigurator;
> import org.apache.log4j.Logger;
>
> public class Bug {
>
> public static void main(String[] args) {
>
> BasicConfigurator.configure();
> Logger logger = Logger.getLogger("bug");
>
> String className = "non-existent class";
>
> try {
> Object o = Class.forName(className).newInstance();
> }
> catch (Exception e) {
> logger.error("error loading: " + className + " : " + e, e);
> }
> }
> }
>
> Does this reproduce the problem? Certain compilers generate corrupt
> binaries on rare occasions. Which OS this by the way? Why do I have to
> ask the same questions over and over again? Is it because your time is
> more
> precious then other's?
>
> At 00:39 24.05.2002 -0700, Kevin Steppe wrote:
>
>> log4j version 1.2.0 released
>>
>> I do have multiple log4j.jar files around, but all are of the same
>> version. There is reason to believe that I may have multiple
>> different versions of -my own- class files lying around that I should
>> hunt down.
>>
>> After some further hunting, the original exception appears to to be a
>> nullPointer exception. That exception was being caught and logged.
>> The logger then caused the VerifyError, crashing the program. If I
>> don't pass the throwable, then the exception is caught cleanly and I
>> get useful information (passing the throwable causes the VerifyError
>> and the underlying caught exception is lost, making the root problem
>> hard to address).
>>
>> Tomorrow I will clean up my own class files, see if that fixes
>> anything and report back. If you have other suggestions for things
>> to try please let me know.
>>
>> Thanks,
>> Kevin
>
>
> --
> Ceki
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
