Ok. More adventures with open source. One of the things I’ve got on my (lengthy) list at the moment is to have a look at some light(er) weight servlet and J2EE containers. JBoss is giving me hives. You may be aware of that, I’ve mentioned it before.
So the first one I wanted to look at was Geronimo, partly because it’s from Apache, party because it’s got the option of being wrapped around either Jetty or Tomcat. I trotted off, grabbed the 2.2.1 tar ball and threw it onto my Mac so that I could run it up on the train. That’s where the irritation started. From the documentation, it was evident that in other *nix environments, I should just be able to unpack the tar ball and run bin/geronimo.sh run. I tried that on my Mac, and was hit by the dreaded Unable To Decrypt error.
It was pretty obvious that there were two parts to the solution: get a full JDK installed on the Mac, and ensure that the run time environment for Geronimo has JAVA_HOME pointing to the right place.
I could rant endlessly about Apple’s arcane treatment of Java, but won’t. If you have a developer account, it’s reasonably easy to grab a fairly recent JDK and get it installed. What’s not so obvious is where the hell the JDK winds up on your machine after install. Apple aren’t particularly helpful with this: the JDK winds up in /Library/Java/JavaVirtualMachines. Hence for me I needed to add JAVA_HOME to my profile:
JAVA_HOME=/Library/Java/JavaVirtualMachines/1.6.0_31-b04-415.jdk/Contents/Home
That sorted Geronimo out nicely – the boot log showed the right JARs were being found:
Runtime Information:
Install Directory = /Users/robert/Desktop/geronimo-jetty7-javaee5-2.2.1
Sun JVM 1.6.0_31
JVM in use = Sun JVM 1.6.0_31
Java Information:
System property [java.runtime.name] = Java(TM) SE Runtime Environment
System property [java.runtime.version] = 1.6.0_31-b04-415-11M3646
System property [os.name] = Mac OS X
System property [os.version] = 10.7.3
System property [sun.os.patch.level] = unknown
System property [os.arch] = x86_64
System property [java.class.version] = 50.0
System property [locale] = en_US
System property [unicode.encoding] = UnicodeLittle
System property [file.encoding] = MacRoman
System property [java.vm.name] = Java HotSpot(TM) 64-Bit Server VM
System property [java.vm.vendor] = Apple Inc.
System property [java.vm.version] = 20.6-b01-415
System property [java.vm.info] = mixed mode
System property [java.home] = /Library/Java/JavaVirtualMachines/1.6.0_31-b04-415.jdk/Contents/Home
System property [java.classpath] = null
System property [java.library.path] = {stuff in java.home}
Nice! Trouble is – the problem persisted. Here’s the trick: the initial install of Geronimo creates various properties files. If that initial startup fails, the properties files have borken information in them, and you will never get it to startup. Let me repeat that:
You MUST get JAVA_HOME in the Geronimo environment pointing to a valid JDK before you try to run Geronimo, or daemons will fly out of your nose and eat your face. You have been warned.
Post a Comment