Solve the Problem caused by Xhost permission
Up to today, our team have struggled for about more than two days to solve a problem: some errors are thrown by AJAX. This error happened oddly, some machines ok, others NOK. But we could not found root cause at our logs even our had added many try/catch to the codes, only finding:
DEBUG Key 'location' was not found on instance of java.lang.reflect.InvocationTargetException.
Introspection information for the class is:
{getClass=public final native java.lang.Class java.lang.Object.getClass(),
localizedMessage=java.beans.PropertyDescriptor@d5a29b8,
cause=java.beans.PropertyDescriptor@287fe5b,
getCause=public java.lang.Throwable java.lang.reflect.InvocationTargetException.getCause(),
from this error, we have known this problem happened during the initialization of class, in our classes, it is the class JDilog, also by the method of Single-step-debugging using Maven to connected remote tomcat application, we can find that the errors are located at the initialization of the JDilog classes.
Based on the fact that the application run Ok at some PCs, NOK at other PCs, we follow the train of thought that there are must be some minor difference between these PCs, so we continually find the three main different points: (1) a kind linux bit address is 64, another kind is 32; (2) the java version: jdk1.6.0.22 and jre 1.6.0.23;(3) there are cases that both JDK and JRE installed. So we deal with our business hardly by debugging these conditions to be the same.
However, after the hard working, although these conditions are identical, the problems still Laughed at US very loudly.
For a long time, the whole team are felt a frustrated feeling, finally, finally, i am always not content the logs printed by application, and doubted about the logs places and why so little logs are printed. One of my peers said that there are some logs at home of tomcat. Then i immediately get to there, and begin of my analysis habit -- Logs Analysis, then finding :
11:27:50,442 [http-bio-8080-exec-5] DEBUG CommonsLogger : Executing action method = getPageEsAccessUseJson
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
then i reported to my supervisor at once, then Everything comes out at last! The problem is caused by Xhost, the JDialog is displayed by the X-Window, if this component is to display, the client should have the right to access X-Window. So, we assign the access rights to the users account running the application using the command 'Xhost +'. Then the problem is solved.
After this problems, i find there are two technique blind points:(1) the what-the-heel usage of JRE and JDK; (2) the Tomcat common issues, such as the log places, how to tune the parameters of tomcat; (3) the X-Window issues, such as the relationship between X-Window and user account.
On problem example:
{2012-06-12 12:53:00,592} ERROR java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
{2012-06-12 12:53:00,592} ERROR
java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(Unknown Source)
at java.awt.image.BufferedImage.createGraphics(Unknown Source)
Athought you can use the xhost + local:username to solve this problem, but there is another good way to solve this problem, that is to use the Headless Mode:
Generally Speaking, add the java.awt.headless parameter to the catalina.sh
CATALINA_OPTS="... -Djava.awt.headless=true"
Enjoy!
Many times, you may need in the shell scripts to run a java program, this java program may locate at jar, or just a class.
this reference is the official document for the java command.
the common commands such as java -version
$ java -version
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)
and other common commands to use java such as java -cp and java -jar could also find information in the above link.
here is a example, in a shell script: dbpass=`cd $shome;java -classpath .:./javabase64-1.3.1.jar AES -d $password`, the command means to invoke the AES class to do continual process (encrpt and decrpt), and the required jar should be use the -cp or -classpath, and note the "." representing the current path.
Introduction of the Expect Tool
Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really makes this stuff trivial. Expect is also useful for testing these same applications. And by adding Tk, you can also wrap interactive applications in X11 GUIs.
Expect can make easy all sorts of tasks that are prohibitively difficult with anything else. You will find that Expect is an absolutely invaluable tool - using it, you will be able to automate tasks that you've never even thought of before - and you'll be able to do this automation quickly and easily.
Note: the expect tool requires the Tcl/Tk tool, but the tcl/tk tool possibly need not be installed by yourself, because tcl/tk come preinstalled on most Unix systems. However, if it is there, you'll want to check if you've got a recent version. To check, start Tcl/Tk (usually via running "tclsh" or "wish" from a command line), and typing "info patchlevel". This will tell you what version you're running.
the home page of Expect tool: http://expect.sourceforge.net/
the home page of tcl/tk tool : http://www.tcl.tk/software/tcltk/
after you get the expect tool gz, you can use the command to get sources of it.
gunzip expect.tar.gz
tar -xvf expect.tar
According to the Expect Readme file, the method to make and install Expect tool is very hard, so the best way to install it using the rpm command. And there are many built Expect Rpm Packages in network, or in the DVD Red Hat Enterprise Official version. Here is a very useful Expect RPM packages link:
Red hat version
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
GCC version
# cat /proc/version
Linux version 2.6.18-164.el5 (mockbuild@x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46))
In the Red hat Enterprise DVD, there are usually four expect related rpms, such as expect-5.43.0-5.1.i386.rpm, expect-devel-5.43.0-5.1.i386.rpm,expectk-5.43.0-5.1.i386.rpm and pexpect-2.3-1.el5.noarch.rpm. Usually, you need the first two rpms, pls install the first one, then install the second one.
After installation, you can use 'which expect' command found the expect tool be installed successfully.
By the way, except the rpm command, you can use the 'yum install expect' to install the expect tool.
Yum
is an automatic updater and package installer/remover for rpm systems. It automatically computes dependencies and figures out what things should occur to install packages. It makes it easier to maintain groups of machines without having to manually update each one using rpm.
Yum
has a plugin interface for adding simple features.
Yum
can also be used from other python programs via its module inteface.