Re: Long shot on a IllegalAccessError - SOLVED!

Thanks again. The verbose setting gave me the clue I needed: It wasn't the jars that I suspected. In Birt there is a /lib folder but many classes get loaded from the /plugins folder. I had deleted the /lib and replaced it several times but I hadn't suspected anything else lurking until I ran the -verbose mode and saw all of the jars loading from /plugins. So I deleted the whole ReportEngine folder on the i and copied the working version from my windows machine and it all started working.

Thanks for the tip. It gave me enough to to start thinking outside the box.

Pete


On 5/2/2010 12:17 AM, Thorbjoern Ravn Andersen wrote:

Den 02/05/10 01.07, Pete Helgren skrev:

I had looked up the Javadoc on it and saw the same rationale. I just
can't quite figure out what this application wouldn't have access to. I
don't think permissions on the jars would be an issue so the Javadoc
seems to only indicate an issue with a method or field that may be
flagged private or something

My second guess would be that you somehow have two different versions of
Birt in play. One seen when compiling and the second one being picked
up in your code.

Might a colleague have left an older one in one of the Java system folders?

You can tell the JVM to be verbose when loading classes. This can be
very helpful in clarifying where code is actually being loaded from.

About two years ago "logback" (a fork of log4j) was extended by a
donation by James Strachan so that stacktraces shows the name and
version of jars. All this requires is to catch this error (can be done
at the top level) and use "log.error("...", e)" to dump it. May also be
included in others like log4j but I have not followed that closely.

He describes it here:
http://macstrac.blogspot.com/2008/09/better-stack-traces-in-java-with-log4j.html

Any idea where the cached jars might reside? This is driving me a little
crazy, knowing that I am on a deadline, I have seen the error and fixed
it (in Windows) and can't find any other explanation for the error.

Usually the caching happens "under" the file itself (you can use "du" to
see the real size including the hidden stuff), so what you have done
should be sufficient.

Good luck