I'm running Groovy Eclipse Monkey 0.4.0 on Eclipse 3.2.1 under Windows XP.
When I try running the example scripts, I get an exception from groovy.jface.factory.PreferencesPageFactory (initialization failure); below is the exception stack track from running OpenDialog_Groovy.gm; it appears in a popup window:
groovy.jface.factory.PreferencesPageFactory (initialization failure)
java.lang.Throwable: org.apache.commons.logging.LogConfigurationException: java.lang.reflect.InvocationTargetException
at java.lang.J9VMInternals.initializeImpl(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: java.lang.Throwable: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
... 36 more
Caused by: java.lang.Throwable: java.lang.NoClassDefFoundError: org.apache.log4j.Logger
... 41 more
I've found that while I can run a simple groovy script like this:
* Menu: New Groovy Monkey Script
* Script-Path: /GroovyMonkeyScripts/monkey/new_file.gm
* Kudos: yarbroug
* License: EPL 1.0
* DOM: http://groovy-monkey.sourceforge.net/update/plugins/net.sf.groovyMonkey.dom
def name='World'; println "Hello $name!"
I get no exception popup, but I do see "Hello World" in the console output, the same exception appears in the Eclipse error log, followed by an Unhandled Loop Event Exception.
Any ideas what could cause this problem?
Hmm... I don't get the error period. Which Java VM are you running? I noticed the J9 in the stack trace above. Its barfing on trying to configure the logger in code that I did not really do anything to. I also checked my latest code in the repository and the line numbers have changed..
So given the above I think there is a set of things we could do.
First if you are not running a Sun Java 5.0 JRE (or JDK), could you try that and see if the error recurs? Also could you pass which java you are running back to me, just to see if I can reproduce the error.
Second, hopefully when I get home today ( February 12 ) I will go an update the update site and the released packages to reflect the very latest stuff in the repository. If the first step does not resolve the issue, hopefully the new build will.
Third, if this problem persists with the Java VM you want to run and the latest version does not resolve this, I could look into disabling the logging messages or address it in another fashion. Hopefully if it persists, I can then reproduce it..
James E. Ervin
Thanks for the response, James. Sorry, it didn't even occur to me to include the JVM information. Duh.
C:\> java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20061002a (SR3)
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-2006100
1 (JIT enabled)
J9VM - 20060915_08260_lHdSMR
JIT - 20060908_1811_r8
GC - 20060906_AA)
JCL - 20061002
I'm unable to use the Sun JVM on this machine for legal reasons (I work for IBM :-)
c:\> java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing)
I have replicated my c:\eclipse directory to another PC that has the Sun JVM, and attempted to replicate the problem there. So far, it seems to work OK. Wierd. I did not replicate the same workspace, so I don't know if there's something in the workspace that could cause this.
One final step I took to try and recreate the problem. On my work PC, I had these jar files installed in JAVA_HOME/jre/lib/ext:
log4j-1.2.14.jar [whoa! could be the culprit]
ostermillerutils_1_06_00.jar* [CSV Parsing utilies]
when I added these to the JAVA_HOME/jre/lib/ext directory on the Sun JAVA machine, Groovy Monkey fails the same way. Could it be that the log4j I have installed in ext is the problem?
Yes, that must be it. I removed the version of log4j in the ext directory on the machine running the IBM JVM, and Groovy Monkey is groovy again :-).
Now, is there a way I can have that log4j jar file and Groovy Monkey too?
The key is the org.apache.commons.logging library. It is being used to configure the logger and it is determining the use of log4j ( or not ). I don't see anywhere in Groovy Monkey where I am bringing the log4j library. Of course it is a very common library, so if you can avoid using dumping it into the ext directory.
I hope you solved your problem and I would love to hear how you resolved it.
Oh, sorry, thought we'd wrapped that up. It was log4j, and I resolved it by removing log4j from lib/ext. I figured out a workaround for having it in the lib/ext directory; I'm using one-jar from http://one-jar.sourceforge.net/ to package up my code and the jars it needs into one jarfile. Seems to work just fine.
Thanks for your help identifying the problem. I'm looking forward to playing with Groovy Monkey in Eclipse.
Oh that sure smells like the culprit...
If I remember correctly putting jars in JAVA_HOME/jre/lib/ext is usually to be avoided, since it has the ability to stick you in Jar hell so easily. The root classpath for everybody is loaded with classes in the ext lib and I believe even overrides the OSGi container's modularized classloader.
So if you don't need to put the jar in the ext lib, don't?
Hopefully that resolves things...
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.