If you're using GlassFish 3.1.2 on a 64-bit OS, you're likely to run into a couple of bugs related to the GlassFish update tool. More likely so, if you've installed GlassFish off the ZIP bundles available at glassfish.java.net - extracting these archives do not install the updatetool utility.
The JVM crash
I ran into a segfault when running the updatetool from the commandline. Portions of the reported fault are listed below:
Proxy: Using system proxy settings.
Install image: /opt/glassfish-3.1.2.2/glassfish3
Installing pkg packages.
Downloading 2 packages.
Downloading pkg (511 files, 6,237,937 bytes).
thread 140690402031360 also had an error]
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ff50b573920, pid=25590, tid=140690403084032
#
# JRE version: 7.0_09-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libdbus-1.so.3+0x26920] dbus_watch_handle+0x1b20
#
# Core dump written. Default location: /opt/glassfish-3.1.2.2/glassfish3/bin/core or core.25590
#
# An error report file with more information is saved as:
# /opt/glassfish-3.1.2.2/glassfish3/bin/hs_err_pid25590.log
Opening the pid error log showed the actual cause:
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.net.spi.DefaultProxySelector.getSystemProxy(Ljava/lang/String;Ljava/lang/String;)Ljava/net/Proxy;+0
j sun.net.spi.DefaultProxySelector.access$100(Lsun/net/spi/DefaultProxySelector;Ljava/lang/String;Ljava/lang/String;)Ljava/net/Proxy;+3
j sun.net.spi.DefaultProxySelector$2.run()Ljava/net/Proxy;+151
j sun.net.spi.DefaultProxySelector$2.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;+0
j sun.net.spi.DefaultProxySelector.select(Ljava/net/URI;)Ljava/util/List;+223
j sun.net.www.protocol.http.HttpURLConnection.plainConnect()V+314
j sun.net.www.protocol.http.HttpURLConnection.connect()V+1
j sun.net.www.protocol.http.HttpURLConnection.getInputStream()Ljava/io/InputStream;+195
j java.net.HttpURLConnection.getResponseCode()I+16
j com.sun.pkg.client.Image.checkRepositoryConnection(Ljava/net/HttpURLConnection;)V+1
j com.sun.pkg.client.DownloadFileTask.download()Ljava/io/File;+73
j com.sun.pkg.client.DownloadFileTask.call()Ljava/io/File;+1
j com.sun.pkg.client.DownloadFileTask.call()Ljava/lang/Object;+1
j java.util.concurrent.FutureTask$Sync.innerRun()V+29
j java.util.concurrent.FutureTask.run()V+4
j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+46
j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
This turned out to be GLASSFISH-18360. Applying the workaround listed in that report was sufficient to bypass the problem - you'll merely need to update the updatetool script to set the value of "proxy.use.system" to false. Of course, this works if you're not using a proxy.
Now, you should be able to install the updatetool utility.
The 32-bit libraries
That wasn't good enough though. Running updatetool after installation, resulted in this message:
Locale could not be determined. Attempting to use English locale.
WX import error. Verify the WX widgets are in the PYTHONPATH.
The following can be reported to GlassFish Update Tool 2.3.5 Development Team <dev@updatecenter.java.net>.
Traceback (innermost last):
File "/opt/glassfish-3.1.2.2/glassfish3/updatetool/vendor-packages/updatetool/common/boot.py", line 283, in init_app_locale
import wx
File "wx/__init__.py", line 45, in ?
File "wx/_core.py", line 4, in ?
ImportError: libjpeg.so.62: cannot open shared object file: No such file or directory
---------------------------------------------------------------
There was an error running
/opt/glassfish-3.1.2.2/glassfish3/updatetool/bin/../../pkg/python2.4-minimal/bin/python
The weird bit about this was that the ia32-libs package required by updatetool was already installed. The problem turned out to be the use of the 64-bit version of libjpeg:
$ locate libjpeg.so /usr/lib/jvm/jdk1.7.0_07/jre/lib/amd64/libjpeg.so /usr/lib/x86_64-linux-gnu/libjpeg.so.8 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2
On 64-bit Mint or Ubuntu, you'll need to explicitly install the i386 version:
sudo apt-get install libjpeg62:i386
That should do be sufficient:
$ locate libjpeg.so /usr/lib/i386-linux-gnu/libjpeg.so.8 /usr/lib/i386-linux-gnu/libjpeg.so.8.0.2 /usr/lib/jvm/jdk1.7.0_07/jre/lib/amd64/libjpeg.so /usr/lib/x86_64-linux-gnu/libjpeg.so.8 /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2
Running updatetool now should bring up the GUI.
5 comments:
Holy shit, awesome. Had exactly this same issue and the workaround worked perfectly. Yay!
thanks a lot.. I had a exact same issue and this workaround worked perfectly.
Excellent - thank you very much!
Saved a lot of time, thanks for this post.
Thank you! It works like a charm!
Post a Comment