May you have all the delicious joe you can ever get into your mug. I can't believe how fast you responded (and on a Sunday (my time) no less)!
$sudo JAVA_HOME=/usr/lib/jvm/java-6-sun ./geronimo.sh run --long
Same result, encryption error.
I then downloaded a farm-fresh installation of Geronimo, validated, unpacked, and ran exactly the same command against the new directory. Success!
I believe the original error confirms the issue previous posters in the thread encountered. Whether the path to JAVA_HOME was explicitly called out or not, once a bad shell command to run Geronimo was executed, the installation became corrupt, and no amount of pointing to the correct JAVA_HOME path would fix it.
As for my environment, /usr/bin/java is as you guessed, a symbolic link. It links to /etc/alternatives/java, which in turn, links to the actual JAVA_HOME. I doubt that link-nesting could cause a problem, but I've been wrong before.
Thanks again for your assistance!
My emailbot's coffee filter just beeped... :)
On Jun 5, 2011, at 12:33 PM, 4lorn wrote:
> Kevan (or any helpful soul),
> I'm encountering a similar error, and would love some assistance if you're
> up for another cup of coffee.This indicates a problem with your JAVA_HOME or JRE_HOME setting.
> I'm running Ubuntu Linux 126.96.36.199-rscloud (Rackspace's Ubuntu kernel) on x64
> architecture with 4GB of memory and plenty of storage.
> Here are outputs of various commands verifying JAVA:
> $ echo $JAVA_HOME: /usr/bin/java
> $ echo $PATH: (includes) /usr/bin/java/bin
> $ which java: /user/bin/java
> $ java -version: java versions "1.6.0_21"
> After reading this thread, I removed a previous Geronimo directory,
> downloaded v2.2.1 from a different mirror, verified the MD5 checksum, and
> unpacked the verified tarball.
> $sudo ./startup.sh from $GERONIMO_HOME/bin fails.
> The first sign of an error in geronimo.log is:
> ERROR [AbstractEncryption] Unable to encrypt
> java.security.NoSuchAlgorithmException: Cannot find any provider supporting
So, /usr/bin/java is a symbolic link to /usr/lib/jvm/java-6-sun-188.8.131.52/?
geronimo.sh (which is invoked by startup.sh) is going to configure -Djava.ext.dirs. In your case it should include something like '/usr/bin/java/jre/lib/ext'. If that directory doesn't contain sunjce_provider.jar (which contains the AES provider), then you're going to see that failure.
FYI, I setup a symbolic link and was able to start Geronimo:
$ ln -s /usr/lib/jvm/java-6-sun-184.108.40.206/ ~/java-symbolic-link
$ JAVA_HOME=/home/kevan/java-symbolic-link/ ./geronimo.sh run --long
Seems to work ok for me. ps aux | grep server.jar gives me the following:
/home/kevan/java-symbolic-link//jre/bin/java -Xmx256m -XX:MaxPermSize=128m -javaagent:/home/kevan/geronimo-tomcat6-javaee5-2.2.1/bin/jpa.jar -Dorg.apache.geronimo.home.dir=/home/kevan/geronimo-tomcat6-javaee5-2.2.1 -Djava.endorsed.dirs=/home/kevan/geronimo-tomcat6-javaee5-2.2.1/lib/endorsed:/home/kevan/java-symbolic-link//jre/lib/endorsed -Djava.ext.dirs=/home/kevan/geronimo-tomcat6-javaee5-2.2.1/lib/ext:/home/kevan/java-symbolic-link//jre/lib/ext -Djava.io.tmpdir=var/temp -jar /home/kevan/geronimo-tomcat6-javaee5-2.2.1/bin/server.jar --long
Have a look at your set up and let us know what your environment looks like.
http://apache-geronimo.328035.n3.nabble.com/ERROR-AbstractEncryption-Unable-to-decrypt-tp445727p3026988.htmlIf you reply to this email, your message will be added to the discussion below:To unsubscribe from ERROR [AbstractEncryption] Unable to decrypt, click here.