Start Local XWindow on Microsoft Windows Platform

In a UNIX network, it is quite natural to connect to an XWindows server from local machine. If your daily work is on a Windows machine, and occasionally do something requiring an XWindows, there are two ways provided by cygwin package, which is a simulator of UNIX environment on a Microsoft Windows platform.

You can start an X server on UNIX side, and use an X client on Windows side. The terminal is a true XWindows, as if you were working locally on the remote UNIX machine. This approach consume more resource on the server side, and sometims it is infeasible in case there are multiple users doing same thing in an organization.

Another way is to start up an X server on local Windows side. Cygwin provides an simulated UNIX environment. Then telnet to remote UNIX machine and direct the X connection back to the local one. Here are the detailed steps.

You should install cygwin + X11R6 package.

On your host 10.10.1.123, run

/usr/X11R6/bin/startxwin.bat

to start local XWindows.

In the shell, add remote host:

xhost 10.10.1.35

Then telnet to 10.10.1.35, assuming you are in csh, and set DISPLAY environment variable:

setenv DISPLAY 10.10.1.123:0.0

Then you can start any XWindows application. Do a test:

xterm &

You will see a UNIX shell window on your Windows desktop. An interesting feature of this approach is that, unlike the first method you get a window for everything on UNIX side, with the second method, each XWindow is dependent. They can be operated in same way as a Windows' window.

Kill Process by Name on UNIX

Here is a ksh script to kill processes by name.
Usage: kill processName

---------------- cut here ---------------------
#!/usr/bin/ksh

str="$1"

ps -ef grep "$str" {
while read aline;do
cmd=`echo $aline awk '{ print $9 }'`
if [ [ $cmd = $0 ] ]; then
continue
fi

cmd=`echo $aline awk '{ print $8 " " $9 " " $10 }'`
if [ [ $cmd = "grep" ] ]; then
continue
fi

cmd2=`echo $cmd grep "$str"`
if [ [ $cmd2 = "" ] ]; then
continue
fi

print "$aline"
pid=`echo $aline awk '{ print $2 }'`
print "kill pid = $pid"
kill -9 $pid
done
}

---------------- cut here -----------------------

Default Transaction Attribute of an EJB is different among WebLogic/WebSphere/JBoss

Here is another difference between WebLogic and WebSphere/JBoss. For WebLogic, the default transaction attribute of an EJB is TX_NOT_SUPPORTED if it is not explicitly defined in ejb-jar.xml. There is no transaction context in the call to the EJB. However, JBoss and WebSphere, the default behavior is different, and there is a new transaction.

WebLogic Only Supports String Type in ActivationSpec

Unlike WebSphere and JBoss, WebLogic only supports java.lang.String type properties in ActivationSpec. WebLogic claims it always strictly follows J2EE specification. Developer can specify properties with wrapped primitive types on Resource Adaptor level in ra.xml:


<resourceadapter>
<resourceadapter-class>
mypackage.ResourceAdapterImpl
</resourceadapter-class>
<config-property>
<config-property-name>convertRate</config-property-name>
<config-property-type>java.lang.Integer</config-property-type>
<config-property-value>123</config-property-value>
</config-property>
……

Maybe it is true that this is the right way, but it is obviously inconvenient to specify only String type in ActivationSpec.

Code Coverage Test with EMMA Utility

Unit test is an essential stage in a software development lifecycle. After the code of features is completed, developer is required to design a number of test cases to guarantee the software performs desired functions.

There is no simple objective criteria how many test cases enough to assure the quality of a software. Being lack of deep knowledge of implementation, project managers reluctantly accept the test plan from developers. The question can not be answered by developer either. Since it is infeasible to exhaust every possible test scenario, the developer is eager to know the minimum number of cases that can touch the most part of the code.

The code coverage test is probably a feasible objective measure. A little open-source utility, EMMA, can generate a precise picture how much percentage the code is covered after the execution of a test suite. The data is broken down to packages, classes, and even methods. It helps the developer design new cases to increase the percentage rather than to repeat similar cases.

EMMA provides a lot of features, and I am very impressed with two of them: It reports rich coverage analysis without introducing significant overhead during either build or execution time. It is simple, lightweight, and easy to probe classes running in a J2EE container. Here is an example where the test suite is designed for foo.jar used by a JBoss application server.

First copy emma.jar into the lib directory of the application server.

Create an instrumented version of foo.jar. Put emma.jar into environment variable CLASSPATH. Create a directory output for the instrumented classes. Execute command java emma instr -d output -ip foo.jar. There is a file coverage.em created under the current working directory. Then package the instrumented classes under directory output into a new version of foo.jar, and replace the JAR file in the application server.

Start the application server. Execute the test suite as usual. Then stop the application server. There will be a raw result file coverage.ec generated under the directory where the application server is launched, in my case, C:\jboss-4.0.4.GA\bin\coverage.ec.

Generated the plain text and HTML reports with command java emma report -r txt,html -in coverage.em -in C:\jboss-4.0.4.GA\bin\coverage.ec. The plain text report is generated in the current working directory coverage.txt. The report in HTML format is generated as coverage\index.html.